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Abstract 

This thesis defines a property called "view-serializability," which formalizes internal consistency 
for a system of nested atomic transactions. Internal consistency is a stronger condition than the usual 
notion of database consistency, because it takes into account the views of transactions which will never 
commit. In a distributed system, local aborts of remote subactions and crashes of nodes can generate 
orphans: active actions which are descendants of actions that have aborted or are guaranteed to abort. 
Because it is not always feasible or efficient to elimate orphans immediately, special care is needed to 
insure that they sec consistent system states when they are allowed to continue running. We investigate a 
particular dynamic detection strategy designed to detect orphans before they violate internal consistency. 
This algorithm piggybacks abort and crash information on the normal messages between nodes. We 
consider a simpler algorithm that only handles orphans arising from explicit aborts. We describe the 
simplified orphan detection algorithm at various levels of abstraction, using an algebraic model 
convenient for describing asynchronous systems. The highest-level model is specified in terms of a 
(virtual) global state. At this level of abstraction we require that the states generated by the model satisfy 
view-serializability. Lower-level models progressively localize the description of the algorithm's 
operation, and the lowest level of abstraction presents a fully distributed model of the (simplified) orphan 
detection scheme. 

Keywords: concurrency control, orphans, transaction, serial izability, 
internal consistency. 
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]. Introduction 

Production of concurrent programs is a much more difficult task than production of sequential 
programs. The sequential nature of human thought severely limits programmers' ability to manage the 
complexity of parallel processes. Distributed environments compound these difficulties; robust programs 
must cope with non-local failures and with incomplete information about the global state of a system. 
Primitives developed for local, sequential programming have proven inadequate for software 
development in distributed, concurrent systems. Additional mechanisms have been suggested which 
allow programmers to think about concurrent programs for distributed systems using largely sequential 
reasoning. 

Current research pJskov82, Best81] stresses use of the atomic transaction as a tool for 
distributed software. Atomic transactions can insulate users from both the effects of concurrency and the 
effects of failures, greatly simplifying reasoning about a system. If transactions are truly atomic, then 
neither users nor the transactions themselves should see the effects of concurrency or failures. Our 
concern is with the internal consistency property of transactions' views. 

Recent proposals have extended the transaction model to include nested transactions, which 
allow sub-pieces of a transaction to run concurrently and fail independently |Reed78, Moss81]. In such a 
system the independent failure of (sub)transactions can generate orphan processes - active processes 
which are running on behalf of a failed transaction. (We will refine and extend this definition below.) 
Orphans complicate the implementation of atomicity; insuring that orphans' views of the system state are 
"consistent" with atomicity requires a more sophisticated algorithm than one which ignores orphans' 
views. 

This thesis develops a formal model of a distributed nested transaction system, and it shows that 
the model satisfies a correctness condition representing "consistency of views." Our transaction system 
model includes a dynamic orphan detection scheme, which detects and exterminates orphans before they 
see inconsistencies. This model is based on the design for the Transaction Manager of the Argus language 
under development by the M.I.T. Distributed Systems Group [Liskov82]. Although the models in this 
thesis simplify both the assumptions made by Argus about the distributed environment, and the specifics 
of the Argus orphan detection algorithm, the results contribute to confidence in the correctness of this 
algorithm. 
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1.1 Nested Transactions 

1.1.1 Transactions and Atomicity 
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1.1.2 Nested Transactions 
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The child transactions of any transaction can run concurrently; their concurrent execution must 
be scrializable. Children can also commit or abort independently; a child commits to its parent, and its 
effects will be undone if the parent subsequently aborts. It follows that permanent changes to the system 
state occur only when top-level transactions commit. 1 (For details of the semantics of nested transactions, 
see[Moss81].) 

Nested transactions provide at least three advantages over single-level transactions: The ability 
to create concurrent children at any level increases the overall parallelism in a system, which might result 
in efficiency gains. Secondly, the independent abort of a child confines the effects of failure to the work 
done by that child; the parent can take an appropriate action without aborting itself. This failure isolation 
improves program robustness and simplifies error recovery. Finally, a program (or a transaction at any 
level) can use (sub)transactions without regard to their internal concurrency. Concurrency need not be 
completely specified at the top level, permitting a decentralized design strategy. 

1.1.3 Distributed Environment 

Two differences between distributed and centralized systems make nested transactions 
particularly appropriate for distributed environments. First, because distributed systems provide real 
concurrency, a systematic method for managing parallelism becomes both necessary and desirable (for 
efficiency). Second, the failure modes of distributed systems are much more complex than failure modes 
of centralized systems because parts of the system can fail independently. For example, one node in a 
network can go down without affecting other nodes, or the network can fail without directly affecting any 
node. The nested transaction model allows applications to isolate these failures naturally. (Failure 
isolation also contributes to node autonomy: an application running at one node maintains control over 
the state at that node even if it spawns subtransactions at other nodes.) 



1. For modifications to remain permanent when nodes crash, each node must provide stable storage, and top-level commit must 
insure that all changes are written to stable storage. 
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1.2 The Argus System 

Although we have attempted to make the models in this thesis relatively general, the Argus 
system has been used as a starting point. We summarize here the characteristics of Argus which are 
relevant to this work. Argus is a programming language intended to support distributed applications; this 
language requires an extensive runtime system (for example, to handle transaction management). For 
details on the language, see [Liskov82]. 

The distributed environment of Argus consists of a set of nodes fully connected in some fashion 
by a network. Nodes can crash at any time, and recover after an arbitrary down period. Storage at a node 
is divided into volatile and stable storage; the contents of volatile storage are lost when the node crashes, 
while the contents of stable storage survive crashes. 

Nodes communicate by sending messages on the network. Delivery of messages is not 
guaranteed: messages can be lost, duplicated, delayed arbitrarily, and reordered (i.e., delivered in an 
order other than the order in which they were sent). The network can be partitioned for any period of 
time. If one node attempts to send a message to another node, it might be unable to distinguish between 
a lost message, a partitioned network, a crashed respondent, or a respondent that is slow to answer. 

Data in the system is partitioned into objects; objects are atomic or non-atomic. We assume that 
all objects are atomic. (Unconstrained use of non-atomic objects is discouraged in Argus; non-atomic 
objects are provided as loopholes to allow users to implement atomic types which are more efficient than 
the "basic" atomic types provided by the system.) While a precise definition of atomic objects is beyond 
the scope of this thesis (sec [Weihl82] for a discussion), we assume that all atomic objects are implemented 
using two-phase locks with a stack of versions as described in [Moss81]. When an action holds a lock on 
an atomic object, other unrelated actions are excluded from accessing the object (Chapter 8 defines a 
structure which models the lock and version stack of an atomic object) 

Computation is carried out through actions, which are atomic transactions. A (sub)action runs 
completely at one node, though it can spawn child actions at other nodes. Remote subactions are created 
by a remote procedure call, which sends a message from the originating node to the remote node. This 
message can contain parameters computed at the parent node. If the message is received correctly, the 



2. Moss distinguishes between read and write operations; we will ignore this distinction for simplicity. 



11- 



subaction runs and can return a message to the parent The child can commit to its parent, in which case 
results can be passed back to the parent with a commit message, or it might abort. The parent can abort 
the child at any time, but this abort is local to the parent's node; the child might still be running at its own 
node. The parent cannot "commit" the child: the child is committed at the parent's node only if a 
commit message is received from the child. Wc say an action commits to one of its ancestors if all actions 
"between" that action and its ancestor commit. We say an action commits through the top level if all 
ancestors of that action commit 

Effects of actions are written to stable storage when their top-level ancestor action commits. A 
two-phase commit protocol insures that the top-level action commits everywhere or not at all (again, 
consult [Liskov82] for details). If a node crashes after an action runs there, and that action has committed 
to its ancestor top-level action, then the crash will be detected during two-phase commit Thus the 
top-level action will be aborted. It follows that a crash which undoes the effects of an action (i.e. a crash 
which precedes the recording of that action's effects on stable storage) guarantees that some ancestor of 
that action will abort. (This ancestor might not be the top-level ancestor: a lower ancestor might abort, 
and then the crashed node would not necessarily be checked at two-phase commit.) 

1.3 Orphans 

An orphan is an active action that is guaranteed not to commit through the lop level. In Argus, 
orphans can be created in two ways: a proper ancestor can explicitly abort, or a crash can occur. 

1.3.1 Creation of Orphans 

Argus allows parent actions to unilaterally abort their children, because user requirements 
might make it unacceptable to wait for confirmation of the abort from the child's node. Complete 
confirmation would require that each aborted child recursively abort its active children; thus the parent 
would have to wait until all descendants of the child were halted. Since one of the main reasons for 
aborting the child might be that the child is not responding (perhaps because of a network partition, or 
because the child's node crashed), waiting for descendants to be halted could delay the parent 
indefinitely. Some applications cannot tolerate the possibility of indefinite delay. 

Since a parent action can abort a child at the parent's node only, aborted children (and their 
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descendants) might still be- active, and might thus be orphans. These orphans are a necessary 
consequence of a user requirement for bounded delay; they are not the result of a "lazy extermination" 
strategy. 

Orphans result from a node crash when an active action at that node has active descendants at 
other nodes. This situation is similar to the case of explicit aborts since the active ancestor is effectively 
"aborted" by the crash. A more complex type of orphan generation occurs when a crash releases a lock 
held by an action which has committed up to some ancestor, but not through the top level. The lowest 
active ancestor, and all its active descendants, become orphans since they are guaranteed not to commit 
through the top level. Since this lowest active ancestor might abort -- or be aborted by its parent ~ the 
crash need not affect higher ancestors. If the lowest active ancestor commits to its parent, the parent and 
all active descendants of the parent become orphans. If the "infected" ancestor commits to its top-level 
ancestor, then the crash will be detected during two-phase commit, and the top-level ancestor will abort 
This type of orphan could be prevented by keeping locks and versions in stable storage. 

1.3.2 Problems Created by Orphans 

Orphans are unpleasant, though necessary, side-effects of aborts and crashes. Since their effects 
are destined to be undone, exterminating orphans cannot do harm. The main concern of this thesis is 
with the possible adverse consequences of not exterminating orphans "soon enough." 

1.3.2.1 Resource Wastage 

Orphans consume resources and compete with non-orphans for these resources. Orphans can 
deadlock with non-orphans, causing non-orphans to be aborted unnecessarily (depending on the 
deadlock strategy). Resource allocation problems are unlikely to be severe unless orphans are created 
very frequently. While efficiency issues might be crucial for a working system, this thesis only addresses 
the semantic problems associated with orphans. 
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1.3.12 Internal Consistency 

The transaction management algorithm described in [Moss81] does not guarantee atomicity 
from the point of view of orphans. Orphans can observe system states which are not consistent with 
serializability (i.e., they can observe the effects of concurrency). Moss's algorithm does not preserve 
internal consistency. The orphan detection algorithm described in the next section is designed to 
guarantee internal consistency. 

We present two examples of such inconsistencies: 

1. (See Fig. 1.1. Note that conventions for figures appear in Appendix I.) Initially integers x 
and y (at different nodes) have values 0. There is an integrity constraint on the system state 
that x = y. Action Al runs, reads x = 0, (does not modify x), and commits to A. A then 
holds a lock on x. (See [Moss81] for a detailed description of the locking protocol.) A then 
spawns action A2 (passing A2 the information that x = 0), and then A aborts (after the 
message is sent to create A2), making A2 an orphan. The abort of A releases A's lock on x, 
allowing B to run to completion and increment both x and y through concurrent children Bl 
and B2. B commits, releasing its locks on x and y. If A2 (now an orphan) is allowed to read 
y, it will view y = 1, which allows A2 to infer that x * y (an "inconsistent" view, since x = y 
will always hold for any serial schedule). 



Fig. 1.1. Orphan from Explicit Abort 
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2. (See Fig. 1.2.) As in the above scenario, integers x and y (at different nodes) have initial 
values 0, and there is an integrity constraint on the system state that x = y. The same events 
occur as above: Al reads x and commits, and A creates A2. Instead of an abort at A, 
however, x's node crashes. This crash releases A's lock on x, and it makes A (and thus A2) an 
orphan. As above, B then runs to completion and increments both x and y. B commits, 
releasing its locks on x and y. If A2 (now an orphan) is allowed to read y, it will view y = 1, 
which allows A2 to infer that x * y. 



It is not clear whether internal consistency is an important concern for a transaction system. 
One might argue that orphans' views are not important, since orphans will be aborted (eventually) 
anyway. Since all actions expect a serializable system history, however, programs might function 
"correctly" only when their views are consistent. Their behavior when views are not consistent might be 
unpredictable or even catastrophic. (For example, an program guaranteed to terminate under normal 
conditions might be non-terminating when faced with an inconsistent view.) Orphans could also transmit 
their inconsistent views to outside parties, via channels which are not under the control of the transaction 
system. For example, when a user interactively debugs a process that is an orphan, he sees the orphan's 
(possibly inconsistent) view. This inconsistency might mislead the user, since he might have no direct 
way of determining that his process is an orphan. A system which permits terminal output by any action 

Fig. 1.2. Orphan from Crash 
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suffers the same problem. (Since terminal output is irreversible, the effects of any aborted action cannot 
be undone. The orphan's output represents a worse problem, however, since this output might reflect an 
inconsistent state.) 

1.3.3 Orphan Detection Scheme 

The basic orphan detection strategy in Argus piggybacks abort and crash information on all 
channels of information flow between actions. This additional information is used to infer that processes 
are orphans; these processes are then exterminated. 

Our execution model ignores crashes; we deal only with orphans arising from explicit aborts. 
(We believe that the correctness condition for internal consistency that we develop in Chapter 3 should 
also apply to a model which includes crashes, although we have not investigated crashes in detail.) We 
present here a brief description of an orphan detection scheme similar to the portion of the Argus 
algorithm which handles explicit aborts. The transaction system model we develop is based on this 
scheme. Our simplified algorithm ignores many of the optimizations envisioned for the actual Argus 
algorithm. 

User programs at nodes communicate via remote procedure calls and returns. In addition to 
these messages, transaction system messages are sent between nodes to update the status of actions as they 
commit and abort. Commit and abort messages update the locks and versions of atomic objects. There 
are many possible strategies for communicating commit and abort information. For example, when an 
action commits or aborts, a commit message could be sent immediately to all nodes where descendants of 
that action have run. Alternatively a querying strategy could be used where queries are sent about the 
status of an action only when another action wants a lock held by that action. (The commit and abort 
messages would then be possible responses to a query.) Our model will not focus on these strategies; we 
focus on the orphan information which is attached to messages whenever these messages are sent We 
regard the return message from a remote procedure call as a commit or abort message, depending on 
whether the child committed or aborted. The return message might include return values, but since our 
concern is only with orphan information we need not distinguish between return messages and 
transaction system messages. 

Our model has three types of messages: create, commit, and abort messages. A create message 
models a remote procedure call. Although in Argus a "create" message will only be sent directly from a 
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parent node to a child node, for simplicity we assume that a create message can be sent indirectly through 
any other node. Communication in our model is very unrestricted; essentially any node can send a 
message to any other node at any time. The messages that a node can send are limited by what is known 
at that node (e.g., a node can only send a "commit A" message if it knows that A is committed), and by 
rules for piggybacking orphan information on messages. 

The orphan information at each node is a list, DONE, of known aborts. Any action which is a 
descendant of an action in DONE is an orphan and is exterminated. Our rules for piggybacking orphan 
information are quite simple: a create or commit message must include the entire DONE list from its 
sending node; this list is added to the DONE list at the receiving node when the message is received, and 
known orphans are exterminated. An abort message need not include any information from DONE. 

The information flow in this algorithm for the example given in Fig. 1.1 is shown in Fig. 1.3. 
When A aborts, the abort message releasing Al's lock on x adds A to x's node's DONE list This DONE 
list is transmitted to B's node when Bl commits. After B2 runs and commits to B, and B commits, y's 
node will eventually learn of B's commit. The message that B has committed will contain the DONE 
from B's node (which now includes A). Thus y's node will know about A's abort. The commit message 
of B releases B's lock on y, but A2 is now a known orphan at y: A2 is exterminated before it can acquire 
the lock on y and see an inconsistent state. 

The flow of crash information is similar to the flow of DONE information. (We describe the 
mechanism only superficially here; the actual algorithm is quite complex.) The basic scheme requires 
each node to maintain a stable crash count, which is incremented during recovery from any crash. The 
orphan information relating to crashes consists of currently known crash counts for nodes plus the crash 
counts seen by actions when they ran at these nodes. An orphan is detected when it is discovered that a 
crash count "depended on" by an action (essentially a crash count for a node at which a committed 
relative has run) is lower than the currently known crash count for the same node. The discrepancy in 
crash counts implies that a node crash must have occurred since a committed relative ran at that node. 
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Fig. 1.3. Orphan Detection 

A runs at node M, B at node N 

A1.B1 run at node X (object x resides at X) 

A2.B2 run at node Y (object y resides at Y) 

(1) Al runs and commits to A; A spawns A2 (A2 has not read y) 

B spawns Bl; Bl waits because A holds a lock on x 
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(2) A aborts; abort message sent to X, releasing lock to Bl. 

Bl increments x and commits; commit message sent to N (with DONE) 



DONE LOCKS/VERSIONS 
U 

A.'a ^B 

y\ / 

Al.c -^ A2 Bl.c 
x,0 x,0 



(3) B2 runs and increments y and commits. B commits, sending commit 
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1.4 Related Work 

1.4.1 Transaction System 

Our transaction system model is based on the design presented in [Moss81]. Moss generalizes 
two-phase locking for nested transactions, and he develops a recovery scheme based on multiple (backup) 
versions of objects. His transaction manager functions in the presence of both node crashes and 
communications failures. He describes distributed algorithms for locking and version restoration, 
transaction management (including two-phase commit for top-level transactions), and deadlock detection. 
Although our formal model ignores many of the complexities that Moss considers (in particular, node 
crashes), it relies heavily on his basic framework. 

A different approach to nested transactions is explored by Reed in [Rced78]. This scheme uses 
timestamps ("pseudo-times") for synchronization rather than using locks. Versions of objects associated 
with old timestamps can be used for backing up a system to a consistent state. It would be interesting to 
attempt to extend our models to a timestamp-based scheme such as Reed's. While our lower-level 
execution models incorporate notions of locks and version stacks, the higher-level models are relatively 
general, relying only on a nesting relationship among actions and on a notion of "accessing" data. 

1.4.2 Orphan Detection Algorithms 

As mentioned above, the orphan detection algorithm we consider is based on the orphan 
algorithm designed for Argus [Liskov82]. Though we are aware of no implementations of orphan 
detection algorithms, Nelson explores several strategies for eliminating the orphans which result from 
node crashes [Nelson81]. (Because his design is not based on atomic transactions, orphans from broken 
locks or explicitly aborted ancestors do not arise: his orphans are simply processes running on behalf of 
ancestors at crashed nodes.) The simplest such strategy is orphan extermination: After a node comes 
back up after a crash, it exterminates all orphans by tracing all outstanding remote calls. As we discussed 
above, an "immediate extermination" strategy would not be practical for Argus because of user 
requirements for a bounded delay. 

Because communications or node failures can delay extermination during crash recovery 
indefinitely, Nelson suggests alternate mechanisms which can be used in these (probably rare) cases. 
Orphan expiration requires that a remote call inherit a time limit from its parent; when the time limit is 
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reached the process running the call is automatically killed. Expiration can cause needless failures since 
processes can be killed even if they are not orphans. The chosen time limit should be significantly longer 
than "normal" execution times to prevent these anomalies. 

Finally, Nelson suggests a scheme which resembles the crash count mechanism in Argus: When 
complete extermination during crash recovery is delayed, a node will declare a new epoch (i.e. increment 
an "epoch" counter). All messages carry the current known epoch from the sending node. If a node 
receives a message with an epoch greater than its known epoch, it must either exterminate all currently 
executing remote calls (assuming that they are orphans), or query the ancestors of remote calls to 
guarantee that they are not orphans. The system reaches equilibrium when all nodes have the same 
epoch. This approach is most similar to the Argus algorithm because potential orphans are detected 
dynamically based on information piggybacked onto normal information paths. 

1.4.3 Formal Models of Atomic Actions 

This thesis is a direct extension of the work described in [Lynch82]. Lynch gives the basic 
definitions for action trees and serializability that we use here. She presents an execution model (at 
several levels of abstraction) based on Moss's transaction management algorithm, and she shows that 
these executions satisfy external consistency. Our work extends the correctness condition for executions 
to include internal consistency, and it modifies the execution models to incorporate orphan detection. 

Traditional concurrency control theory generally deals only with single-level transactions. The 
usual approach is to define a dependency relation among transactions based on reads and updates, and to 
show that acyclicity of this relation implies serializability (see [Papa79J, for example). The basic theory of 
two-phase locking and serializability for single-level transactions is developed in [EGLT76]; this work 
forms a basis for Moss's system and hence for our models. 

A formal model for nested atomic actions is developed in [Best81]. This model is based on a 
dependency graph for events, where the notion of "dependency" is left uninterpreted. Atomicity is 
defined in terms of "collapsing" an event graph to replace a set of events (the events from an "atomic" 
action) with a single (higher-level) event Sets of events are configured in a tree structure, representing 
the nesting relationship of actions. Acyclicity of inter-action dependencies is shown to be sufficient for 
atomicity. (Lynch uses a data dependency relation to derive a similar acyclicity condition for 
serializability.) The authors also define a condition which they claim is a generalization of two-phase 
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locking, and they show that this condition implies atomicity. 

The main difficulty with this dependency graph model is that the graphs cannot be easily related 
to executions of a transaction system. The action trees developed by Lynch are simply summaries of 
execution histories; "dependencies" are absent at this level of abstraction. (Although Lynch defines 
lower level "augmented" action trees which include an ordering on accesses to data, the "dependencies" 
expressed by this ordering reflect actual modifications to data in an execution sequence.) The advantage 
of this approach is that Lynch is able to define execution models formalizing a transaction management 
algorithm, and to prove that her high-level serializability condition is satisfied by these models. This 
connection between execution models and correctness conditions (for "atomicity") is not explored in 
[Best81]. We have followed Lynch 's approach: we define a condition modeling internal consistency at a 
high level (the level of action trees), and we develop (at several levels of abstraction) a model of an 
orphan detection strategy which guarantees this property. 

1.5 Outline of the Thesis 

Before attempting to show that our orphan detection strategy is correct, we must develop a 
considerable amount of formal machinery. Chapter 2 presents the basic action tree model as described in 
[Lynch82J. (Some parts of this chapter are taken directly from [Lynch82]; though these definitions and 
theorems are not original work of this thesis, we include them here for completeness of presentation.) 
Serializability is defined for action trees, and a theorem is given relating serializability to acyclicity of data 
dependencies. 

Chapter 3 defines "view-serializability," which models internal consistency. We present a 
detailed argument explaining why this formal condition corresponds to our intuitive notion of "consistent 
views." The condition is defined in terms of the action trees and serializability definitions of Chapter 2. 

Chapter 4 develops a general execution model for asynchronous systems, die "event-state 
algebra." We explore a strategy for hierarchical correctness proofs: A correctness condition for 
executions of a system is defined using a high-level model of its behavior (an algebra); tower-level models 
are then defined which are progressively closer to the "real" system, and mappings are described between 
adjacent levels. We also describe distributed event-state algebras, which model distributed systems. 

Chapters 5 - 10 define successive levels of event-state algebras modeling a transaction system 
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with orphan detection. The correctness condition (vicw-scrializability) appears at Level (the highest 
level of abstraction). Level 7 (the lowest level of abstraction) is a distributed event-state algebra. At each 
new level we also construct a mapping to the previous (higher) level. 

Chapter 11 summarizes our results, and suggests possible directions for extensions to this work. 
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2. Action Trees and Serializability 

This chapter gives basic definitions and lemmas for action trees and serializability. We define a 
structure called an "action tree, " which is an abstraction of an execution sequence of a nested transaction 
system. Serializability (and related properties) are expressed as properties of action trees. This approach 
presents minimal constraints on the implementation of a transaction system since we make few assumptions 
about the details of concurrency control and recovery algorithms. 

2.1 Notation 

If S is a set, and o is some order which totally orders the elements of S, then «S; o» denotes the 
sequence consisting of the elements of S in the order given by o. 

If S is a set, then 3(S) denotes the powerset of S (the set of all subsets of S). 

If S is a set, and f: S -► «fl(S), then we associate f with the obvious relation on S ({(s,t): t € f(s)}), and we 
use standard notation for relations. Thus we refer to the closure of a set under a function, we describe a 
function as acyclic, etc. f" 1 " denotes the transitive closure of f, and f* denotes the reflexive-transitive 
closure off. 

12 Action Summaries and Action Trees 

111 Actions and Objects 

Let obj be a universal set of data objects. For each x € obj, let valuesfx) denote the set of 
values x can assume, including a distinguished initial value, initfx) . A value assignment is a total 
mapping f: obj -*• values(obj), such that Vx € obj, ftx) € values(x). 

Let a& be a universal set of actions (i.e., transactions). Let Ji be a distinguished action. We 
assume that the actions are configured a priori into a tree, representing their nesting relationship, with U 
as the root For every A € act - {U}, let parentfA) denote the unique parent action for A. Then 

siblings = {(A,B) € act 2 : parent(A) = parent(B)} 

If A € act, then children(A) = {B € act: parent(B) = A}. LetlflD. = children(U). 
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flnc(A) = the set of ancestors of A, desc(A) = the set of descendants of A 
prop-anc(A) = anc(A) - {A}, prop-desc(A) = desc(A) - {A} 

For A € act - {U}, define crcatorfA) as follows: 
A € top =» creator(A) = A 
A C top =» creator(A) = parent(A) 

If A,B € act, then let lca(A.B) denote the least common ancestor of A and B. Let 

related = {(A,B) € act 2 : A € anc(B) V B € anc(A)} 
unrelated = act 2 - related 

(Note that (A,B) € unrelated => lca(A.B) I {A,B}.) 

If S is a set of actions such that V A,B C S, (A,B) € related, then we say S i§ an ancestor chain . 

If B € anc(A), then let AJJ} denote the single element of anc(B) D children(lca(A,B)). (Note that if A € 
prop-anc(B), then lca(A,B) = A, and A|B € children(A).) 

It might be convenient for the reader to think of this a priori configuration of all possible actions 
into a tree as a preassigned "naming scheme" for actions. That is, the "name" of an action is assumed to 
carry within it information which locates that action in this universal tree of actions. In any particular 
execution, only some of these possible actions will be "activated." The (virtual) action U, the parent of all 
top-level actions, has been added for the sake of uniformity. 

Let sgjfl C siblings be any fixed partial order, representing sequential dependency. If (A.B) € 
seq, then A is constrained to run before B. For the sake of notational simplicity, we are assuming this 
relation is also fixed a priori; we assume that the "name" of any action carries within it information about 
which siblings the action can assume have completed. The use of an arbitrary partial order is a 
generalization of both the total order usually specified for the steps which occur within a single-level 
transaction, and the unconstrained order usually specified among the transactions themselves. 

We also assume a priori determination of which actions actually access data, which objects they 
access, and the functions they perform on those objects: Let accesses denote the leaves of the tree 
described above. (We assume U t accesses, so that the set of actions is nontrivial.) Let object : accesses 
-»• obj be a fixed function representing which object is read by a particular access. If object(A) = x, we 
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say that A is an a£££§§ 1q x., and we write A € aecessesfx) . For A € accesses, let updateM) : 
values(object(A)) -♦ values(object(A)) be a fixed function. Let sameobiect denote {(A,B) € accesses 2 : 
object(A) = object(B)}. 

We define the relation of one set of actions covering another. This concept will be useful for sets 
of aborted actions used to detect potentially "harmful" orphans. The covering relation will express the 
fact that a set has enough information to detect a harmful orphan. Let R,S C act be any sets of actions; 
we say £ cQvgE R, and we write R < S if and only if for each element A in R, there is an ancestor of A 
in S. The following lemma gives elementary properties of the covering relation: 

Lemma 2.11.1: Let R,S,Q,T C act, A € act, then 

a. RCS=»R<S 

b. < is transitive: R < S A S < T =» R < T 

c. (R < S A Q < T) => R U Q < S U T 

d. R < S A anc(A) D S = =» anc(A) D R = 

Proof: Straightforward from the definition. I 

2.2.2 Action Summaries 

We describe an abstraction of execution sequences, using a structure called an "action 
summary." An action summary records the status of a particular set of actions (actions can be active, 
committed or aborted). It also records the data values read by committed accesses. A slightly simpler 
structure, an "unlabeled action summary" (or UAS) records the same information except for the data 
values. An "action tree" is any action summary which is a tree: 



where 



An acjion summary , S, has components yffljccsg, a^, cijnHjjittejijj, aborted^ , and JaM,, 



- verticcsg is a finite subset of act 

- activc s , committcd s , and aborted^ comprise a partition of vertices^ (These classifications 
indicate the current status of each known action. When an action is first created, it is classified as active. 
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At some later time, its classification can be changed to either committed or aborted. By "committed," we 
mean that the action is committed relative to its parent, but not necessarily committed permanently. 
Permanent commit of an action would be represented by classification of all ancestors of the action, 
except for U, as committed.) 

- label s : datastepsg -> values(obj), (where datastcps^ = committedg D accesses), with labelg(A) 
€ values(object(A)). (The label of an access to an object is intended to represent the value read by that 
access. Since the access has an associated function, the value which the access writes into the object is 
deducible from the value read, and therefore need not be explicitly represented.) The read and update of 
an access are assumed to occur "instantaneously" when the access commits. (If an access aborts, it has no 
label because it never sees the object) 

Let done s = committcd s U abortedg. Let status^ fAl = 'active' (respectively, 'committed', 

aborted') provided A € active s (respectively, committedg, aborted^. Let accesses- = verticeSg D 

accesses, accesses s (x) = vertices^ D accesses(x), and djiasiej2s s (x) = datastcps s D accesses(x). Let S£fl s 

= seq n (verticesg) 2 . Letanc-seq s = {(A,B) € verticeSg 2 : 3B' € anc(B) H vertices s : (A,B') € seq}. Let 

childrenJ A) = children(A) n verticeSg. 

An unlabeled acjjoji summary has all components described above except labeL. An action 
Use, T, is an action summary where verticc^ is a tree rooted at U: If A € vertices,. - {U}, then parent(A) 
€ verticeSp 

If T is an action summary, then unlabeim is the UAS obtained by omitting label p Definitions 
and lemmas for UAS's carry over to action summaries in the obvious way (by applying them to 
unlabelfT)). 

2.2.3 Visible and Dead Actions 

We describe actions whose existence is intended to be known to other actions (i.e. which are not 
masked from those other actions by intervening aborts or active actions). We describe these properties 
for UAS's; corresponding definitions and lemmas hold for (labeled) action summaries and action trees. 

Let T be a UAS. For A € act, let asjbJe^A) = {B € vertices,.: anc(B) n prop-desc(lca(A,B)) 
C committed^. That is, visible^ A) is just the set of actions whose existence is (potentially) known to A 
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in T, because they and all their ancestors, up to and not including some ancestor of A, have committed. 
For A € act, x € obj, let yjsjbJe a <A,x) = visible^A) n datasteps^x). Let invisible ^) = vertices,. - 
visible^A). The following lemma, which describes elementary properties of "visibility," is proved in 
[Lynch82]: 

Lemma 12.3.1: Let T be a IMS, A,B,C € act 

a. A € desc(B) A B € vertice^ =» B € visible^ A) 

b. A € visible^B) « A € visible T (lca(A,B)) 

c. A € visible^B) A B € visible^C) => A € visible^C) 

d. A C desc(B) A C € visible^B) =» C € visible^A) 

e. A € desc(B) A B € verticeSj. A A € visible^C) =» B € visible^C) 

Actions which are not visible to another action might be masked by an intervening abort, or by 
active actions only. If B is masked from A by an intervening abort, we say B. is dad IQ A in 1: ifTisa 
UAS, and A € act, we define dgajijXA) = {B € vertices,.: ane(B) n prop-desc(lca(A,B)) n abort^ * 
0}. Note that visible^) n dead^A) = 0. If A € act, x € obj, then dsad^A,x) = dead^A) PI 
datasteps^x). If B is not dead to A in T, we say that fi jg Bye. & A in I. If A € verticeSp then we say A is 
M ia I iff anc(A) n abortedp = 0, and A JS d£2d in I otherwise. If T is a UAS, A € verticeSp and A 
is dead in T, then we define the crural afeon flf A in I. denoted cmciaL /Ak as the lowest aborted 
ancestor of A in T: i.e., if S = anc(A) D aborted^ then crucial,<A) € S, and VB € S, cmciaL/A) € 
desc(B). (If A is not dead in T, then crucial^A) is undefined. In this case we will consider that 
{crucialj<A)} = 0, for convenience.) 

Let T be a UAS, A € verticeSp then we define 

y^ssfl^A) = {B: (B,A) € seq A B * A} fl visiblc^A) 

tSsa-jM) = {B: (B,A) € seq A B * A} n invisible^) 

iancssa^A) = {B: (B,A) € anc-seq T ABC anc(A)} fl visible^A) (see Fig. 2.1.) 

tanc^ssfl^A) = {B: (B,A) € anc-seq T ABC anc(A)} D invisible^) (see Fig. 11.) 
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vghilfl^A) = childrcn(A) n visible^A) 
i-childi<A) = children(A) fl invisible^) 
v-desc^A) = desc(A) n visible^A) 
i-desc-^A) = desc(A) n invisible^) 

2.3 Augmented Action Trees 

We define a new structure called an augmented action summary (or AAS). We can regard 
AAS's as action summaries with an additional component: an ordering on the datasteps accessing each 
object. Formally we define an AAS as a pair T = <S,0>, where S is an action summary, and 0: obj -»• 
9(sameobject), where for all x € obj, 0(x) is a total order on datasteps^x). (Thus 0(x) C datasteps^x).) 
If T = <S,0> is an AAS, then we define em§g(T) = S, qsMH = 0. We extend our notation for 



Fig. 2.1. Visible and Invisible Ancestor-Sequence 



P 
B.C — ^A' 



\ 
\ 
A 



B € v-anc~seq T (A) 



P 



B,8 — * A' 
\ 
\ 
\ 
\ 

V A 
B € i-anc-seq T (A) 



(or B could be active) 
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componcnis and functions of action summaries to components and functions of AAS's in the obvious 

way, by applying them to crasefT). (For example if T = <S,0>, then we will use "vertices,." to refer to 

vertices,,.) Definitions for action summaries and UAS's carry over to AAS's in the obvious way (by 

applying them to erase(T) or to unlabcl(erasc(T))). If T = <S,0>, then we define dat^ = U O(x) . 
a * € obj 

An augmented action use (A AT) is an AAS where erase(T) is an action tree. 

Let T be an AAS, A € vertices^ then we define 

v^ata^A) = {B: (B,A) € data, A B * A} D visible^A) 

tdata^A) = {B: (B,A) € data.,. A B * A} n invisible^) 

v-data-anc^A) = L){A|B} 
B € v-daia^A) 

i-data-anc-^A) = UicruciaUB)} 
B€i-datyAf 

v-precedes ^A) = v-anc-seq T (A) U v-child^A) U v-data-anc^A) 

i-precedes^ A) = i-anc-seq T (A) U i-child^A) U i-data-anc^A) 

The "visible precedence" relation, v-precedes,, will be used in Chapter 3 to define a "view tree" 
which represents an action's view of an execution history. We state here some elementary properties of 
this relation. 

Lemma 2.3.1: Let T be an AAS, A € vertices,. Then 
B € v-precedes^A) =» parent(B) = lca(A,B). 



Proof: 



1. B € v-anc-seq^A) => (B,A') € seq for some A' € anc(A), and B * A'. Thus 
parcnt(B) = parent(A') = ka(A,B). 

2. B € v-child^A) =» parentfB) = A = lca(A,B). 

3. B € v-data-anc^A) => B = AJb for some b € accesses. Thus B € 
children(lca(A,B)), =» parent(B) = lca(A,B). I 



Lemma 13.2: Let T be an AAS, A € vertice^ Then B € v-precedes^(A) 
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B € visibly A), and B € committedp 

anc(C). 

a <r\e nrw meC => B € visible^C). But B* 
But B € v-precedes^(A) - B C v-prccedes^C) for some C, fi- 

ancee), by Lemma 2.3.1, so B C committed,.. ■ 

Le^.2.3.3: 1-Tb.- AAS. A € .mte,, B € vs^A). H- 

a. vsetjj(B) C vset/A) 

b. v-desc-j^CvsetjXA) 

c. v-data^BjCvset^A) 

h ..finition v-desc.-closure (b) follows inductively from 
Proof: (a) is obvious from the definition, des^ 

v-childrgv-precede^-WeshowCc): 

SupposeCev-data^B). Then B1C € v-data-ane^B) 
_ BlCCvset^A), since vset^A) is v-precede^-closed. 

C€vWbte I (B)-.C€rdcK I OUQ. 
Butvse^isv-desc.-closedbytb)^ CCvset^A). 

™~,*v for view sets (the view set itself is not 

ancestor closed, but the view set of an action tog 

ancestor-closed set). 

if w - vseUA) U prop-anc(A), then W is 
lOTma U.4: L«T be an AAS. A € veruce^. IfW - ««,« ) P 

anc-closed. 
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prop-anc(A) => anc(B)C prop-anc(A) C W, anc-closure follows. 

Basis: A € W, anc(A) € {A} U prop-anc(A). 

Induction: Assume B € V, anc(B) C W, and take C € v-precedes^B). By Lemma 2.3.1, 
parcnt(C) = lca(B.C) => prop-anc(C) C anc(B) C W. But C € V => {C} C W =» anc(C) 
CW. I 



2.4 Serializability 

We define serializability for action trees. Let T be an action tree. A partial order p C siblings 
is linearizing for T provided p totally orders all siblings in T. A linearizing partial order p induces a total 
order, induced^, on accessesp in die obvious way: (A,B) € induced,. « (BlA.AjB) € p. If A € 
accesses.,^) and p is a linearizing partial order for T, let preds f (A) denote the sequence «{B € 
visible T (A,x): (B,A) € induced,. p A B * A}; inducedp ». 

If x € obj and s is some finite sequence of accesses, then we define result (x.s) as follows: If s is 
the empty sequence, then result(x,s) = init(x). Otherwise let s = s'A, where A € accesses. Then 
result(x,s) = update(AXrcsult(x,s')) if A is an access to x, = results') otherwise. 

A linearizing partial order p for T is said to be a serializing partial order for T provided p is 
consistent with seq, and label^A) = result(x,preds Tp (A)), for all A € datastcps^x). This definition says 
that the value seen by each datastep is equivalent to the result of a serial execution in the order given by 
p, where only committed actions have any affect T is said to be serializable provided there exists some 
serializing partial order for T. 

15 Serializability of Augmented Action Trees 

An AAT, T, is serializable iff erase(T) is a serializable action tree. It is convenient to define a 
stronger condition than serializability for AATs, which we call "data-serializability." An AAT, T, is 
dflta-scrialjzablc iff there exists p, a serializing partial order for eraseCT), with the additional property that 
induced^ is consistent with datap Obviously if T is data-serializable, then it is serializable. 

Data-serializability has a cycle-free characterization similar to those in usual concurrency control 
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theory. First, we give a definition which says that the label of each access describes the correct object 
value which the access should see, if the versions of objects are ordered according to the data f order. 
Formally, an A AT is version-compatible iff for every object x € obj, and every A € datastepsJx), it is the 
case that label T (A) = result(x,s), where s = «v-data T (A); data f ». The following theorem is proved in 
[Lynch82]: 

Theorem 2.5.1: An AAT, T is data-serializable if and only if both of the following are true: 

a. T is version-compatible. 

b. There are no cycles of length greater than one in seq T U sibling-data^ 

2.6 Restrictions of Trees 

It is often useful to project an action tree (or an AAT) onto a particular set of vertices. We call 
the resulting action summary a restriction of the original tree. 

Defn 2.6.1: Let T be an action tree (or an AAT), V C verticeSj.. We define the restriction pi 
I is V, denoted T|V, as follows: (let S = T| V) 

verticesg = V 

Vv € V, status s (v) = status^v) 

VA € datastepsg, labcl s (A) = label^A) 

If T is an AAT, then datag = V 2 n dataj. 

We say S i§ a restriction oj T iff S = TlverticeSg. We say S is a. subtree of T iff S is a 
restriction of T which is also a tree rooted at U (i.e. vertices is anc-closed). 

Stating the simplest correctness requirements for executions only requires consideration of 
actions whose effects become "permanent." For an action tree (or AAT), T, we define a restriction of T to 
all actions which have committed through the top level: Dermffl = T| visible^). It is easy to verify 
that pcrm(T) is a subtree of T. 

The following lemma shows that if an action has no descendants in datastepsp then it cannot 
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affect scrializability of T: 

Lemma 2.6.2: Let T be an action tree, A € verticesj. - {U}. If desc(A) n datastepsj. = 0, 
then T is serializable if and only if TKverticeSj. - desc(A)) is serializable. 

Proof: LetT= TKverticeSp - desc(A)). 

First we show T serializable =» T serializable. Let p be a serializing partial order for T, and 
let p' be p restricted to vertices^ Then p' is obviously a linearizing partial order for T. Let 
B € datastepsj,. 

label^B) = label r (B) = resulKx.predSj. p (B)), since p is serializing for T. But desc(A) D 
datastepsj. = 0,=» predSp p .(B) = prcd&j. (B). Thus p' is a serializing order for T. 

Now assume T is serializable, and let p' be a serializing partial order for T. Let p be any 
linearizing order for T that is consistent with p'. Let B € datastepSp Then B € datastepSp. 

label^B) = label r (B) = result* x.predSp p ,(B)), since p' is serializing for T. But desc(A) D 
datastepsj. = 0, =» pred^-p^B) = prcdSp (B), since p is consistent with p'. Thus p is a 
serializing order for T. I 

We will frequently use trees that are restrictions of the global action tree with die exception that 
the proper ancestors of one action are considered active (instead of whatever status they have in the global 
action tree). We term this process "backing up" an action tree since we are effectively undoing whatever 
commits or aborts of the proper ancestors might have occurred. This construction will be useful for 
defining trees representing the "view" of an action, since the action will believe its proper ancestors to be 
active (whether or not they have already committed or aborted). 

Defn 16.3: Let T be an action tree (or an AAT), A € verticeSp We define the tree 1 backed 
UBlbiaugil A, denoted T//A, as follows: (let S = T//A) 

verticesj = vertice&j. 

B € prop-anc(A) =» status^B) = 'active' 

B € vertice&j. - prop-anc(A) =» status^B) = status^B) 

VA € datastepsj, label s (A) = label^A) 
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If T is an AAT, then data s - data.. 

Finally, for functions from actions to sets of actions wc will occasionally want to exclude some 
actions from the domain of a function. The set of actions excluded will always be the proper ancestors of 
a particular action, so wc define exclusion with respect to this action: 

Defn 2.6.4: Let f: act -* ^act). We define the exclusion of f from A, denoted f//A, as the 
function: 

(f//A)(s) = fls), if s € prop-anc(A), 
= 0, ifs€ prop-anc(A) 
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3. View-Serializability 

This chapter presents a correctness condition for action systems, which we call view-serializability. 
The definitions relating to view-serializability are developed using action trees: no specific execution model 
for generating these trees is yet assumed View-serializability is intended to model "internal consistency:" a 
system which generates only view-serializable action trees will not allow actions to see inconsistent stales, 
even if these actions are orphans, 

3.1 External Consistency and Internal Consistency 

A fundamental property of atomic actions is that the effects of their concurrent execution 
should be "equivalent to" an execution where each action is run in isolation, and (if the action commits) 
to completion. Different notions of "equivalence" give rise to different conditions modeling atomicity. 
External consistency of a transaction system requires that for any execution the view of an observer 
outside the system is identical to the view that would result from some serialization of this execution. 
There might be interaction between an action and a user which is outside the scope of the "system" (e.g. 
output to a terminal, which cannot be undone when an action aborts). Since a transaction system can 
only make guarantees about the states of objects under system control, we will ignore the effects of 
"extra-system" communication on serializability. (Insuring consistency in such an environment is the 
responsibility of user programs. At this level, "consistency" is an application-specific concept: for some 
applications terminal output from actions which are later aborted might be acceptable, for example.) 
Given this restriction, only actions which commit through the top level can affect the system state as seen 
by an outside observer. 

Internal consistency requires that the effects of concurrency are masked from any action in the 
system. If a system provides external consistency, then all actions which commit through the top level 
must see system states consistent with some serial schedule. Other actions might see inconsistent states, 
however. In particular, the views of orphans are not considered for external consistency, since orphans 
cannot commit through the top level. 

We model external consistency by requiring that perm(T), the subtree of the action tree 
consisting of all actions which commit through the top level, be serializable. In [Lynch82], a model for a 
distributed transaction system based on the locking protocol developed in [Moss81] is shown to be 
externally consistent: Lynch shows mat for all action trees, T, generated by the model, perm(T) is 
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scrializable. 

To see that serializability of perm(T) is not sufficient to guarantee internal consistency, consider 
the example from Fig. 1.1 The consistency constraint x = y is violated for action A2, but permfT) (which 
consists of U, B, Bl, and B2) is scrializable. 

Although serializability of perm(T) is not sufficient for internal consistency, serializability of the 
entire action tree is not necessary for internal consistency. We can easily construct action trees for 
executions which we believe are internally consistent (since no action can see an inconsistent state), but 
which are not serializable. Consider the example shown in Fig. 3.1. Again, the integrity constraint on 
the system state is x = y. Initial values of x and y are 0. Action Bl runs first, views x = 0, and then 
aborts. Then actions A1,A2,B2, and B3 run (in that order). Al and B2 increment x, and A2 and B3 
increment y. The tree is not scrializable, because A must be serialized before B (since B2 views x = 1), 
yet Bl did not view the effect of Al. The tree is internally consistent, however, because no particular 
action was able to observe x * y. (Bl viewed x = 0, but it had no information about the value of y. Since 
Bl aborted, it did not pass its view of x to the rest of B.) 

Thus serializability of the entire action tree is too strong a condition for internal consistency. 
We need a weaker condition which takes into account the views of aborted actions and orphans as well as 
the views of actions that commit through the top level. 

In the following sections we will define the possible "views" of each action in an action tree, and 
we will state a condition modeling internal consistency which is based on serializability of these views. 



Fig. 3.1. Non-serializablc, Internally Consistent Action Tree 
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Using this definition, the only view for action U will be perm(T); thus our formal "view" for action U 
corresponds to our intuitive notion of the view of an "outside observer." Our condition for external 
consistency will then be a special case of our condition for internal consistency. 

3.2 Information Flow and Information Trees 

3.2.1 Information: Object Values and Execution Histories 

Internal consistency requires that any action's view of the system state must be consistent with 
an "illusion" of serial execution. To formalize internal consistency, we must attempt to be precise about 
what constitutes an action's "view" in a particular system state. A simple approach would try to capture 
the knowledge mat an action has of the current values of objects. Thus for the example in Fig. 1.1, we 
might say that action A2 knows that x=0, and if A2 is allowed to read y then it will know that x=0 and 
that y = 1 (an "inconsistent" view). 

A definition which describes the view of an action as a (partial) binding of objects to known 
values is not sufficient to handle more complex examples, however. Suppose that action A creates 
concurrent children Al and A2 to read and update object x. x is a boolean object, assuming only logical 
values (0 and 1). Both Al and A2 read x, and perform a logical not operation on x. Al returns the value 
0, and A2 returns the value 1. If A cannot determine which child ran first, then it is unsure of the 
"current" value of x. 

This uncertainty about "current" values can affect our notion of "consistency." Suppose, for 
example, that action C creates child CI to read object x, and CI returns the value x= 1. C then creates 
concurrent children C2 and C3, passing them the "information" that x = 1. But C2 and C3 both read and 
increment x. Depending on which action runs first, the later one will see an "inconsistency" between 
what its parent told it (x=l) and the current state (x=2). But if both C2 and C3 realize that the other 
might have run first, then both can explain this potential "inconsistency." 

These examples illustrate that direct information about the "current" value of an object is only 
available to accesses which direcdy read that object All other information is "hearsay," in a sense, 
because it expresses only what another action saw or was told. We thus regard the "information" 
available to an action as its knowledge of the execution history of the system: an action might know with 
certainly that action B read y=5, but it cannot automatically assume that the value of y is 5. By treating 
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information as information about execution histories, we can explain the seeming ambiguities and 
conflicts described in the examples above. For the first example, A's information is that Al read x=0 
and A2 read x = 1. In the second example, the information available to C2 and C3 is that "CI ran and saw 
x= 1." Neither C2 nor C3 can conclude that the current value of x is 1. If C2 were run sequentially before 
C3 (and C had no other children), then C2 could conclude x=l. This conclusion of C2 depends on a 
serializability assumption, which is a basic part of consistency, and on C2's knowledge of the structure of 
other actions (in this case knowledge that no siblings can intervene between CI and C2). We elaborate on 
these points in the following sections. 

3.2.2 Paths of Information Flow 

In designing system algorithms to guarantee consistency, we often take a "worst case" approach 
regarding information flow among actions. To define an action's view in this sense, we must consider all 
possible sources of information about the execution history to an action. We say that information flows 
from action A to action B if B learns something about the execution history from A. The actual value(s) 
passed from A to B will generally be some function of the values of objects seen by A; we lose no 
generality by assuming that A passes B its complete knowledge of the execution history. Again, this 
assumption amounts to a worst-case approach for information flow: If action A reads object x, and A 
passes some information to B, B does not necessarily have specific "information" about the value of x 
seen by A. The actual values passed from A to B might be constants, for example, giving B no 
information at all about the execution history. But since B might have any information that A might have 
had, we will assume mat it does. 

Let A be an action whose view is being defined. We imagine that actions arc encapsulated in 
procedure-like structures, with well-defined inputs and outputs. Thus we assume that information can 
flow to A only in the following three ways: 

1. If A is an access to x (and A commits), then A reads the value of x. 

2. parent(A) passes information to A when A is created. 

3. Committed children of A pass information to A when they return (i.e. when they commit to 
A). 

Path (3) is limited to committed children, reflecting an assumption that aborted children do not 
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pass "information" to their parents. If aborted children are allowed to return values to their parents (as in 
Argus), then this assumption can be violated. In Argus, return values from aborted children are a 
recognized "loophole" in the system. We retain our assumption because it models the fundamental 
semantics of "abort" which are derived from atomicity: An atomic action runs completely or not at all. If 
an atomic action aborts, all effects should be as if it had never run at all, and an action which never runs 
cannot return values. 

A more subtle assumption is that the very fact that a child has aborted cannot give the parent 
any "information" about the execution history, other than the fact that the child aborted. A child which 
reads object x might be programmed to commit if it sees x = 1, for example, and to abort otherwise. If the 
child aborts, one might think that the parent could then assume that the child read x and found x*l. 
However, we make a basic assumption that an action can be aborted at any time by the system, and that 
the parent cannot necessarily distinguish between a system-initiated abort and an abort caused by the 
child itself. For example, the system might abort a child because of a communications failure, even if the 
child were going to commit. (In a practical system, such as Argus, it might be useful to identify the cause 
for a system-initiated abort, so the parent will know how to proceed. These explanations for aborts fall 
into the same "loophole" category as return values from aborted children.) Given the assumptions that 
aborted children cannot return values, and that aborts are always possible, whatever the system state, 
aborts serve as impenetrable barriers to information flow. 

3.13 Circularity of Information Flow 

We would like to describe the information available to an action in an action tree by listing all 
the actions which are (potential) sources of information to that action. Our formulation of the three paths 
of information flow is not convenient for this purpose, because it contains a confusing circularity: 
information flows from a parent to its children, and also from a (committed) child back to its parent By 
naively following the paths of information flow we would conclude that an action is a source of 
information to itself, which makes no sense. Of course this circularity is fictitious, because the flow of 
information from parent to child happens at a different time than the flow of information from child to 
parent 

One approach based directly on the three paths of information flow above would be to define 
the information available to an action as a function of time. By including time as a parameter of available 
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information, the circularity described above can be removed (i.e. "available information" will no longer 
be recursively defined). We would like to describe the information available to an action without 
referring to time, however. Although the information available to an action does change as an execution 
proceeds, we would like to capture the maximum amount of information that an action sees during an 
execution. Since an action's information can only increase over time, an action attains its maximum 
information at its latest active point in an execution (if it completes, this point is immediately before it 
commits or aborts). 

We achieve a "time-independent" definition of available information below by reformulating 
the paths of information flow. The alternate formulation contains no circularity. 

3.2.4 Information Flow from Siblings of Ancestors 

We remove the circularity in the paths of information flow by "short-circuiting" flow through 
ancestors: 

Information can flow between sibling actions via the parent only if one sibling commits before 
another is created: upon commit, the first sibling passes information to its parent, and the parent passes 
this informauon to the next sibling when creating it (There can also be indirect information flow via 
objects.) In some systems, this path of information flow might allow an action to see information known 
by any sibling which had committed before the action was created. We assume that flow of information 
between siblings (via the parent) is restricted to flow from sequentially preceding committed siblings. We 
are making an assumption here that the control structure of actions does not permit direct flow of 
information between concurrent siblings. (This assumption holds in Argus, because all concurrent 
siblings must be created "at once" by a cocnter statement. It is impossible for a concurrent sibling to 
commit before another is created; thus it is impossible for information to flow directly between mem. 
Concurrent siblings cannot communicate except by modifying shared objects.) 

Thus we can list the the sources of information to A's parent which can serve as sources of 
information to A (when A is created): (1) Sequentially preceding committed siblings of A, (2) Any action 
which was a source of information to A's parent when the parent was created In "unwinding" this 
recursion, we can define the sources of information to A when A is created as all actions which are 
committed and sequentially precede some ancestor of A. We thus obtain an equivalent definition of the 
sources of information to an action by replacing (2) above with a path of information flow from these 
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sequentially preceding committed siblings of ancestors: 



2. Information passed from B to A, where B has committed, and B sequentially precedes some 
ancestor of A (B € v-anc-seq^A)). 

Using this second formulation we can give a single definition of the (maximum) information 
available to an action in any particular execution history (i.e. for any action tree). With the new 
specification of information source (2), the only paths of information flow arc from committed actions 
(and from objects). We assume that committed actions release their complete (maximum) information to 
other actions when they commit 



3.2.5 Information Trees 

Since we are using action trees as an abstraction of execution histories (and hence of system 
states), we describe an action's view of the history as a particular (backed up) subtree of the (global) 
action tree. We call this tree the information tree, for an action. We can think of the information tree for 
action A as being defined recursively: it is constructed by merging all the information trees of actions 
from which information can flow to action A. 

Because an action might be aware that some actions have aborted, these aborts should strictly be 
included in the information tree. (If action A sequentially precedes B, for example, then B will know that 
A has either committed or aborted.) Although aborts are part of the execution history, we have argued 
above that they convey no additional information. (In other words, the existence of an abort tells an 
action nothing other than that the abort occurred.) For simplicity, then, we exclude these aborted actions 
from the information tree. 

The vertices of the information tree for an action are simply all vertices reachable by "tracing 
back" the three paths of information flow listed above. Since the information tree is a subtree of the 
global action tree, path (1) is accounted for by the labels of datasteps. (In other words, if a datastep is 
labeled with V in the global action tree, it will be labeled with "u" in the information tree. This value 
read is part of the execution history of the datastep, and should thus be included with the datastep.) Path 
(2) requires that if B is in the information tree, and C € v-anc-seq^B), then C is in the information tree. 
Path (3) requires that if B is in the information tree, and C is a committed child of B, then C is in the 
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in formation tree. 

Defn 3.2.5.1: Let T be an action tree, A € vertices^ We define the information set of A in T, 
info-set j/A) = (v-anc-seq T U v-childj.) (A) 

And we define the information tree of A in T, 

info-tree -pTA) = (T|W)//A, where W = info-set^A) U prop-anc(A) 

We include proper ancestors of A in the information tree, but since information has only flowed 
through these ancestors from sequentially preceding committed siblings, we do not include them in the 
information set The proper ancestors are considered active since A will regard them as active. (Thus the 
information tree is "backed up" through A.) It is possible that some of these ancestors might have 
committed or aborted, but these changes in status should not be visible to A. 

The following lemma gives an equivalent definition of the information set which is easier to use 
because it does not involve closures of functions. 

Lemma 3.2.5.2: Let T be an action tree, A € verticeSp Then 

info-set^A) = v-desc^v-anc-seq^A) U {A}). 

Proof: Let V = info-sct^A) = (v-anc-seq T U v-child T )*(A), and let W = 
v-desc^v-anc-seq^A) U {A}). It is obvious that W C V. We show VCWby induction on 
V: 

Basis: A € V, but A € W because A € v-desc^A}). 

Induction: Let B € V, and assume B € W. Take C € v-child^B) U v-anc-seq^B). We show 
C€W. 

Since B € W, B € v-desc^B'), for some B' € v-anc-seq^A) U {A}. If C € v-child^B), then 
C € v-desc^B'). If C € v-anc-scq.^B), then either C € prop-desc^B'), or(C.B') € siblings, 
or C € v-anc-seq-jXparentfB')). 

If C € prop-desc^B'), then C € v-desCpCB"). 

If (C,B') € siblings, then (C,B') € seq, =» C € v-anc-seq^A), by transitivity of seq. 
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If C € v-anc-scq 1 -(parcnt(B')), then C € v-anc-seq^A). I 

We now use this equivalent definition of the information set to prove three simple lemmas 
about information sets and information trees: 

Lemma 3.2.5.3: Let T be an action tree, A € verticesp W = info-sct^A) U prop-anc(A). 
Then W is ancestor-closed. (Thus the information tree is in fact a tree.) 

Proof: Let B € W, C € prop-anc(B). We must show C € W. Let V = info-set^ A). If B € 
prop-anc(A), then C € prop-anc(A) =» C € W. 

If B € V then B € v-desc^v-anc-seq^A) U {A}), by Lemma 3.2.5.2. If B € v-desc^A}), 
then C € v-dcsc^A}) U prop-anc(A) =» C € W. 

If B € v-desc^v-anc-seq^A)), then either C € v-desc^v-anc-seq^A)), or C C anc(A), =* C 
€W. I 



Lemma 3.2.5.4: Let T be an action tree, A € vertices,,. Then prop-anc(A) n info-set^A) 
0. 

Proof: Follows directly from Lemma 3.2.5.2. I 



Lemma 3.15.5: Let T be an action tree, A € verticeSp and let S = info-tree^A). Then 
vertieesjj C visible^A). 

Proof: Follows directly from Lemma 3.2.5.2. I 



3.3 Behavioral Constraints and View Trees 

The information tree represents all information about the execution history which might be 
available to a particular action as a result of information flow in this execution (except for information 
about aborts.) For this information to be "consistent," it must not contradict the assumptions an action 
might have about the system's behavior. One of these assumptions is the illusion of serial execution: no 
action should see the effects of concurrency. Failure atomicity also requires that no action should see the 
effects of aborted actions. An action might have additional expectations about the system's behavior, 
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however. Often these expectations are captured in invariants on the system state which all actions 
preserve (when run in isolation and to completion). An action might function correctly only if a 
particular invariant holds. (Its effects when the invariant does not hold might be unexpected or 
unspecified.) 

To develop a notion of "consistency," we imagine that an observer is placed at an action and is 
given that action's information tree. The observer is also informed of any invariants on the system state 
that are preserved by all actions in isolation, and he is told that the system executes actions in some serial 
order. (Of course, the actual order might not be serial, but the observer should be unaware of this 
interleaving.) There are two types of inconsistencies which he might find: (1) The observer sees the 
effects of concurrency. For example, action A spawns child Al to read x (no update), and finds x = 1. 
Then A spawns child A2 (sequentially following Al) to read x, and A2 returns x = 2. (A has no other 
children.) This situation is clearly inconsistent with serializability. (2) The observer might deduce that 
the system state violates an invariant. For example, an observer at action A2 in Fig. 1.1 would see x * y. 

The first type of inconsistency can be prevented by requiring that the information tree be 
serializable. Serializability of the information tree is too strong a condition, however, because the effects 
of other actions might be visible (through data objects) even though these actions are not in the 
information tree. 

Since we want to formulate a consistency condition which does not depend on particular 
invariants for particular applications, we will increase the amount of information we presume is available 
to an observer. In other words, we will provide a sufficient consistency condition, which might not be 
necessary to insure consistency in all cases. We now assume that an observer at an action has complete 
knowledge of the set of possible behaviors of all other actions in the system (when run in isolation and to 
completion). We might imagine that the observer is given program listings for all actions, for example. 
This knowledge is sufficient to determine any invariants. (In a sense invariants are just one way of 
specifying certain aspects of program behavior.) Other than the actions in his information tree, he does 
not know what particular actions have actually run in the current execution, but if he is told that a 
particular action did run he can deduce the possible effects that it had (by checking his program listings). 

The observer's view is consistent if he can explain the values in his information tree with a serial 
execution that conforms to the known behaviors of all actions. We stress again that the observer does not 
know what actions have run, but he can construct hypothetical execution histories based on his program 
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listings. This condition is existential: an information tree is consistent if there exists a serializable "view 
tree" which contains the information tree and agrees with known behaviors of actions. 

The problem with a condition defined in terms of program behaviors is that the transaction 
system does not have the program listings available to it (in a useful form). We imagine now that a 
"transaction manager" is placed at an action, and given its information tree. The transaction manager 
must decide whether the information tree is "consistent." The transaction manager will design algorithms 
to insure that an observer does not sec an inconsistent state, but the manager does not have access to the 
program listings. But the transaction manager can devise a sufficient test for consistency: Since every 
action must run according to its program, the actual behavior of any action in the current execution must 
be among the allowed behaviors. Thus the transaction manager will try to create a "view tree" by taking 
actions from the real global action tree. (Of course, the observer cannot see this global tree.) Another 
way of looking at this restriction is to imagine that the program listings given to the observer are modified 
so that the only possible behavior of an action is the behavior it exhibited in the current execution. 

The known behaviors of an action might include aborted actions as well as committed actions. 
For example, action B might run child B2 sequentially after child Bl in every execution. If B2 runs it can 
conclude that Bl has either committed or aborted. Moreover, if B commits, any other action can 
conclude that Bl committed or aborted, and that B2 committed or aborted. Note that if B aborted, then 
another action cannot conclude anything about Bl or B2 (since they might never have run at all). 

Strictly speaking, the transaction manager should include these known aborts in its view trees, 
because they are part of "behavior." Just as we argued that there is no need to include these aborts in 
information trees, we can argue that there is no need to include them in view trees: Since aborted actions 
provide no information about their proper descendants, these proper descendants need not be included in 
the view tree. But aborted actions without descendants cannot affect serializability (by Lemma 2.6.2), so 
it is sufficient for the transaction manager to test for a serializable view tree which does not include these 
known aborts. It suffices for the transaction manager to choose actions for the view tree which are visible 
to A. (In other words, if a serializable view tree exists which includes these aborted actions, then it will 
still be serializable when the aborted actions are deleted. Thus we lose no generality by considering only 
view trees which do not contain these aborted actions.) 

We place two restrictions on the selection of actions for this hypothetical view tree. First, the 
transaction manager must choose actions that are visible to the action whose tree he is constructing. 
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Second, because the behavior of an action might depend on any information available to it, if the 
transaction manager includes any action in his view tree, he must include the entire information tree of 
that action. 

Example: We consider again the scenario presented in Fig. 1.1. Suppose that except for 
action A, the top level actions in the system each create two (sequentially related) subactions; 
the first subaction reads and increments x, and the second subaction reads and increments y. 
(Action A simply reads x and then reads y.) The initial values of x and y are 0. The 
information tree for A2 from the tree in Fig. 1.1 indicates that x - 0, y = 1. If the transaction 
manager were allowed to create a view tree which included only part of action B (i.e. included 
descendant B2 but excluded Bl), he would conclude (wrongly) that A2's view is consistent 

Note also that the status of proper ancestors of the action should be 'active', since the observer 
should be able to believe that its proper ancestors are active (though in fact they might have committed or 
aborted). We include these proper ancestor in the view tree, but we exclude them from the information 
set closure requirement because (as discussed in the section on information trees) we have short-circuited 
these ancestors with our definition of information flow. (Thus we require the vertices of the view tree to 
be info-setjy/A-closed, rather than info-setp-closed) 

For convenience, we separate the scrializability requirement from the other requirements, and 
we define a view tree as any tree which satisfies the proper closure properties. 

Defn 3.3.1: Let T be an action tree, A € vertices^ Let S = (T|V)//A, for some set V C 
vertices We say S is a view tree for A in T iff 

1. A € V 

2. V is anc-closed 

3. V is info-setp/M-closed 

4. V^visible^A) 

(Note that A € V and V is info-setj/M-closed «• info-tree^A) is a restriction of S.) 

It is important to stress again that there is not enough information in action trees alone to 
determine Ibi view tree for an action: a view tree is one of possibly several explanations for an 
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information tree. As a trivial example, suppose that actions Al, A2, and B read object x in this order, but 
never update it. (See Fig. 3.2.) Then any combination of actions that includes B forms a serializable view 
tree for B. 

For AATs . we will define a particular view tree, using the data ordering. To conclude that this is 
necessarily Jjie view tree is incorrect: use of this particular view tree requires assumptions about how 
versions of objects are modified. We will use this view tree for one of our system models, but again note 
that the definition of a view tree is independent from the construction of this particular view tree. 



Fig. 3.2. Multiple View Trees 



Global action tree: 



Al.c 
x.O 




A2,c 
x,0 
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One view tree for B: 
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Another view tree for B: 
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3.4 View-Serializability 

The view of an action is "consistent" if it can be explained with a serializable view tree. An 
entire tree is "view-serializable" if every action has a serializable view tree. 

Dcfn 3.4.1: Let T be an action tree. We say T is view-serializable provided the following is 
true: For each A € vcrticeSp there exists a serializable view tree for A in T. 

View-serializability is our basic correctness condition modeling internal consistency. In fact 
view-serializability is a strong enough condition to model external consistency as well: The following 
lemma shows that perm(T) is the only possible view tree of the (virtual) top-action, U. 

Lemma 3.4.2: Let T be an action tree. Then S is a view tree for U in T if and only if S = 
permfT). 

Proof: Suppose that S = (T|V)//U is a view tree for U in T; we show that S = perm(T). But 

prop-anc(U) =0«S = T|V. 

Since V is info-setjV/U-closed, V is info-setj.-closed (again, because prop-anc(U) = 0). 

Thus V is v-childj-'dosed, =» v-desc^U) C V (since U € V). 

Butv-desCj{U) = visiblc 1 <U) =» visible^U) C V. 

But V C visible^U), since S is a view tree for U. 

Thus V = visible^U), => S = Tlvisible^U) = perm(T). 

Conversely, let S = perm(T); we show S is a view tree for U in T. As above, S = 
(Tlvisible^lOy/U. Let W = visible^U). We show that W satisfies the correct closure 
properties for view trees. 

1. U € W, since U € visible^U). 

2. If A € W, then anc(A) - {U} Q committed^ If B € anc(A) - {U}, then anc(B) - 
{U} Q committedp -» B € W. If B = U, then B € W by (1) above. Thus W is 
anc-closed. 

3. We show that W is info-setjy/U-ctosed, i.e. if A € W • {U}, and B € 
info-set^A), then B € W. But A € W - {U} =» A € visible^U). by defraitkra. B 
€ info-set,<A) =» B € visible^A), by Lemma 3.2.5.5. Thus B € visible^U) by 
Lemma 2.2.3.1c, =» B € W. 
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4. W C visible^U) by definition. I 

Thus view-serializability implies serializability of perm(T); our condition for external 
consistency is covered by our condition for internal consistency. 

Lemma 3.4.3: Let T be an action tree, then 
T is view-serializable =» perm(T) is serializable. 

Proof: Immediate from Lemma 3.4.2. I 

3.5 Augmented Action Trees and Data-closed View Trees 

We extend all definitions and lemmas for information sets, information. trees, view trees, and 
view-serializability to AATs in the obvious way (by applying them to erasefT)). (There is a subde point 
that the definition of restriction of an AAT is different from the definition for an action tree, since a 
restriction of an AAT includes the data ordering from the original AAT. But the data ordering does not 
enter into any of the preceding definitions or lemmas, and erase(T)|V = erase(T|V) for all AATs, T, and 
action sets, V.) 

For AATs we define a particular view tree by augmenting the information tree via a type of 
data-closure. For the models that we will consider (in which only explicit aborts are allowed, and versions 
of objects change only in response to explicit commits and aborts), this view tree will be used to show 
view-serializability. 

Defn 3.5.1 : Let T be an AAT, A € verticesp Define vtree^ A) as follows: 

Let V = vset^A) ( = v-precedes|(A)) 
The components of S are as follows: 

~ vertices^ = V U prop-anc(A) 
- statuSg is defined by 

1. B € V - {A} => status^B) = •committed* 
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2. status^A) = status^A) 

3. A' € prop-anc(A) - V =» statuSg(A') = 'active' 

- If B € datastepsy then label s (B) = label^B). 

- datag = data T D vertices^ 

Unlike the situation for information sets, the view set of an action might include proper 
ancestors of that action. (This case occurs only when the view set "cycles back" to ancestors of the action; 
proper ancestors are not originally included in the view set) The following lemma shows that vtreey(A) 
is a view tree for A if these cycles do not occur: 

Lemma 3.5.2: Let T be an AAT, A € verticesp S = vtree^A). If prop-anc(A) n vset^A) = 
0, then S is a view tree for A in T. 

Proof: Let V = vsetjXA), W = V U prop-anc(A). First we show that S = (T|W)//A. 

By definition, verticeSg = V U prop-anc(A) = W. If B € V - {A}, then status^B) = 
'committed'. But by Lemma 2.3.2, status^B) = 'committed'. For B € prop-anc(A) - V, 
statuSgCB) = 'active', by definition. But prop-anc(A) n V = =» prop-anc(A) - V = 
prop-anc(A). Thus B € prop-anc(A) =» status^B) = 'active'. For action A, statuSg(A) = 
status^ A), by definition. Thus the trees S and (T| W)//A agree on the status of all actions. 

It is trivial to verify that these trees agree on all labels, and on the data ordering. 
Now we show that W satisfies the correct closure properties for view trees: 

1. A € W by definition 

2. W is anc-closed by Lemma 13.4. 

3. We show that W is info-setjy/A-closed, i.e. that (info-setp/MXW) Q W. But 
by definition, info-setjy/A is on prop-anc(A), and is identical to info-seu 

' otherwise. Thus we must show info-setj^V) Q W. 

But V = vsetyCA) «» V is vse^-closed by Lemma 2 J 3a. 

vsetj. = vprecedesj = (v-anc-seq T U v-childj. U v-data-anCj)*. But 

info-setj. = (v-anc-seo^. U v-child,.)* 

Thus info-set,<V) Q vsetj<V). 

Thus V is vsetj.-closed -» vset^V) Q V, => info-set^V) Q V, «» 
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info-scL r (V) C W. 

4. V C visiblc T (A), prop-anc(A) C visible^A), 
=» W C visiblc T (A). I 



We will show in Chapter 6 that these cycles can only occur for view sets of orphans, and that the 
orphan detection strategy which we present will eliminate these cycles. 

As examples of the construction of these data-closed view trees, vtree T (A2) for the tree of Fig. 
1.1 is the entire tree, and it is not serializable. For the tree of Fig. 3.2, vtrec T (B) is also the entire tree, but 
it is serializable. 
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4. Event-State Algebras 

This chapter defines our basic execution model: the event-stale algebra. An event-slate algebra is 
a stale- transition model of a system where events can occur asynchronously. A correctness proof for an 
event-state algebra shows that the stales generated by valid event sequences satisfy some property. A strategy 
, of hierarchical correctness proofs is explained: We define mappings between event-state algebras, and we 
give conditions on these mappings which insure that they preserve validity of event sequences. Finally, we 
present a model for distributed systems which is a special case of event-state algebras. 

4.1 Event Algebras 
4.1.1 Notation 

If S is a (finite or infinite) set of symbols, then S* denotes the set of finite sequences of symbols from S, 
including A -- the empty sequence. We will often drop the distinction between a symbol and a sequence 
of length one. 

Jf denotes the set of non-negative integers, and |u| € Jf denotes the length of sequence u. 

If sequence u is a prefix of sequence v, then we write u < v. (Context will dictate whether "<" refers to 
the prefix relation on sequences or to numerical order on integers.) We say a set of sequences, W, is 
prefix-clpsed if and only if all prefixes of every sequence in W are also in W: (Vv € WXu < v =» u € 
W). 

If u € S* is a sequence, and e € S, then we write e € u iff e is among the elements of u. (Note that, a 
priori, e might be repeated in u many times.) We denote by -^ the ordering on elements of u,i.e. ife,f 
€ S, then 

e ~u f ** u = a'e»b»f»c, for some sequences a,b,c € S*. 

Note that -+ is transitive for any u € S*. It is not necessarily acyclic, since elements of a sequence can be 
repeated. 
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4.1.2 Events and Valid Execution Sequences 

An event algebra is a behavioral model of a system which describes the events in the system, and 
some constraints on "valid" executions imposed by the system. An execution of a system is any sequence 
of events from the system; the valid execution sequences will be some subset of these sequences. This 
type of model is useful for describing systems where events occur asynchronously and independently (as 
opposed to a program model, for example, where the allowable sequences of events are governed by a 
(generally sequential) program). It is also useful for describing properties of sequential systems which do 
not depend on the order of events (or depend on weaker ordering constraints than those enforced by the 
system). 

At this level of description, "events" are completely uninterpreted: they should be regarded as 
textual symbols only. The only structure imposed by an event algebra is the set of valid execution 
sequences. 

Defn 4.1.2.1: An event algebra is a pair 

JL = (8, t) 

where 8 is a set (called the events of ^t), and 

fis a prefix-closed subset of 8 (called the valid execution sequences of J). 

(We will generally use symbols "e,f,g" to refer to individual events, and "u,v,w" to refer to sequences of 
events.) 

We can consider the general problem faced in reasoning about a system to be showing some 
properties of the valid execution sequences. We are not interested (at this level) in how the system 
enforces the constraints on execution sequences. The valid execution sequences are simply a specification 
of the "correct" behaviors of the system. 
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4.1.3 Interpretations 

We would often like to view a system at a higher level of abstraction than the one at which it is 
defined. In this section we describe an abstraction process for event algebras, and we show how this 
process can be used to organize proofs of system properties. 

Dcfn 4.1.3.1: Let J. x = (8 r fj), and JL 2 = (8 2 , T 2 ) be event algebras. An interpretation 
from A. \q A± is a mapping h: 8 X -*• 8 2 . 

An interpretation, h, is valid iff h(tj) C tj. 

Note that any event sequence in one algebra can be interpreted as any sequence in another 
algebra: there are no constraints on this mapping. Although most interpretations of interest will have 
more structure (for example, h might be monotonic), it is not necessary to introduce this structure for 
these general definitions. 

In proving a property of valid execution sequences for some event algebra, it might be useful to 
state this property as a constraint on execution sequences of an event algebra which is at a higher level of 
abstraction than the low-level model of the system of interest (We might be interested only in particular 
events, for example, or we might regard a sequence of events as a single event at a higher level.) We 
might also want to break this abstraction process into several steps, constructing event algebras at 
intermediate levels of abstraction. We must then define valid interpretations between successive levels. 
Soundness of this technique follows directly from the following lemma: 

Lemma 4.1.3.2: Let JLy X^, J.^ be event algebras. If g is a valid interpretation from X^ to 
JL 2 , and h is a valid interpretation from X 2 to JLy then h°g is a valid interpretation from X^ to 

Proof: Straightforward. I 

Of course, we must be careful in applying this technique to be sure that the composition of 
mappings from lower-level algebras to higher-level algebras is consistent with the abstraction we desire 
from the lowest-level event sequences to the "abstract" event sequences. 

We can reduce any problem of proving a property of valid execution sequences to an equivalent 
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problem of constructing a valid interpretation: Suppose J^ = (6 r TJ is an event algebra, and P C 8* is 
some property of execution sequences. We want to show that P holds for all valid execution sequences in 
J. v i.e. that ^ C P. We can construct a "higher-level" algebra, JL^ whose valid execution sequences are 
just those specified by P: ^ = (6 p P). If we define interpretation h from ^ to ^ as the identity map 
on event sequences, then TJ C P if and only if h is valid. 

By defining a top-level event algebra whose valid execution sequences automatically satisfy a 
desired property, we create a very uniform structure for our proofs: A "correctness" proof consists of 
definitions for a sequence of algebras, definitions for interpretations between levels, and proofs that all 
interpretations are valid. 

4.1.4 Evcnt-Homomorphic Interpretations 

We defined interpretations very generally as any mapping between event sequences. Usually 
natural interpretations will have more structure, which will simplify a proof of validity. We define here a 
class of interpretations called "event-homomorphic" which allow the interpretation of any sequence to be 
constructed inductively from an interpretation of each event in the sequence. 

Defn 4.1.4.1: Let^= (6 r TJ) and J. 2 = (6 2 ,r 2 ) be event algebras, and h: g* -> g* be 
an interpretation from ^ to X r We say h is an event-homomorp hir interpretation iff 

Vu,v € 6* h(uv) = h(u)h(v) 

(Note that if h is event-homomorphic, then h(A) = h(A A) = h(A)h(A); thus h(A) = A.) 

If an interpretation, h, is event-homomorphic, then the image of any sequence can be 
constructed from the images of each element in the sequence. Thus we can specify an 
event-homomorphic interpretation as a mapping h: 6, -*• g* 

Note that for an event-homomorphic interpretation, individual events in the lower-level algebra 
can be interpreted as any sequence of events in the higher-level algebra. A lower-level event which maps 
to A is effectively "abstracted out" at the higher level. A lower-level event which maps to a single event is 
visible at the higher level, although different lower-level events might map to the same higher-level event 
To model the usual notion of "abstraction," where several "concrete" events might implement a single 
"abstract" event, we could map the earlier steps of the concrete sequence to A, and map the last step to 
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the abstract event 

Our notion of "abstraction" is unusual, however, in that the image of a single lower-level event 
might be several higher-level events. We allow this case because the "observer" of a system might not be 
able to see the granularity of events directly: he might only see their effects (e.g. through changes in 
"state" caused by events). An "abstraction" in this sense might be a higher-level way of explaining these 
effects. It is possible that higher-level events can be "simpler" to understand, even though they are less 
"powerful" in that several higher-level events are needed to explain a single lower-level event 

We will deal only with event-homomorphic interpretations; in the remainder of this paper, 
"interpretation" always means "event-homomorphic interpretation." 

4.2 Event-State Algebras 

4.11 Events as State Transitions 

Although our notion of the behavior of a system depends only upon the events in the system 
and the valid execution sequences, it is often convenient to describe a system by referring to a "system 
state." Specifically, we can abstract from event sequences to "states" by interpreting events as operations 
on a state. We introduce a structure called an "event-state algebra," which includes state as a basic 
system component 

Following [Stark83], we regard the events in a system as the fundamental entities; we introduce 
states for convenience in specifying the valid event sequences. The concept of "state" allows us to 
describe valid event sequences inductively by giving "preconditions" on the current state for each event 
Because it is often simpler to reason incrementally about system behavior, states are a useful specification 
device. From this perspective, a system could be described (equally well) by several event-state algebras 
using different state spaces; these different state spaces would simply represent different ways of 
summarizing execution histories. 

Dcfn 4.1 1 J : An event-state algebra is a quadruple 

•X= (6.2,ff,r) 

where 8 is a set of events . 



56 



2 is the set of system states . 

a € 2 is the initial system state, and 

tC8 X2X 2 is the transition relation. 

Let r(e) = {(s,t) € 2 2 : (e,s,t) € t}. 

For convenience, we require that T(e) be a partial function on 2, i.e. 

(e,s,tl), (e,s,t2) € t =» tl = t2. 
(We could allow r(e) to be an arbitrary relation, modeling a nondeterministic choice of the 
"next state." Because we will not need this power, we restrict r(e) to a partial function.) 

We regard -r(e) as a total function on 2 U {_L} (where J_ represents "undefined") by 
defining 

r(eXJ_) = JL, and 

T(eXs) = J_ for s € 2 if there is no pair(s,t) € r(e). 

If s € 2 U {X} and e € 8, then we write 

se for T(eXs) 

We generally drop the distinction between the event e and the partial function r(e) when the 
meaning is clear. We extend our notation to sequences of events in the obvious way: 

(sXe ie2 ...e n ) = (((sje^)..^) 

If u € 8*, then we say a\s is the result of execution sequence u. (Note that the result might 
be_L.) 

If 3u € 8*: s2 = (sl)u, (for si, s2 € 2) then we write si h- s2 in A, and we say s2 is 
reachable from si in £. We will simply write si I- s2 when the algebra is clear from 
context 

If H C 6*, and s € 2, then we define 

sH = {su: u € H} 

(Similarly if S C 2 and u € 8*, we define Su, or if S C 2 and H Q 8 , we define SH.) 
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?U), the set of vajjal execution sequences of JL, consists of all sequences whose result is 
defined (i.e. each event in the sequence is defined on the result of the preceding sequence): 

e € H.JL) «=> ae * J_ 

%,(J), the set of reachable states in J., is the set of all states that are reachable from the initial 
state: 

S>U) = {s € 2: a h- s} (Thus9b(.X) - o!{J.).) 
We extend this definition to sequences of reachable states as follows: 

%< n \j.) = {< Sl ,s 2 ,s n > € 2 n : a h- s 1 h- s 2 ... h- s n } 

Note that ^ n \j.) C (3>U)) n . 

We will use boldface symbols to refer to vectors of states, e.g. s = <s,,s, s >. 

We denote by PRE^(e) the proper domain of T(e), for each e € 6. (PRE^(e) = {s € 2: 
r(eXs) * _L}.) We generally drop the subscript when the algebra is clear from context We 
extend this notation to sequences u € 8* by defining: 

PRE(u) = {s € 2: su * ±} 

(In general, if an event-state algebra is named "JL n " for some subscript, "n", then we will 
abbreviate tU n ) as "1^", %U n ) as "% n ", and PRE^ as'TRE,/') 



We are viewing event-state algebras as convenient structures for specifying event algebras. We 
say that an event-state algebra X = (8\ 2", a \ r) & a EESSejUation flf event algebra .A = (S, t) if and 
only if 6' = 8 and %X) = X. (Note that %X) must be prefix closed by construction.) It follows from 
this definition that several event-state algebra presentations might exist for a given event algebra, but each 
event-state algebra is a presentation of a unique event algebra. If JL' is a presentation of JL, then we say 
that J. is the embedded event algebra fnr JL\ 

We can show that an event-state algebra presentation exists for any event-algebra ~ the 
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degcnerate presentation whose state is the entire execution history: 

Lemma 4.11.2: For any event algebra J. = (8, t), there exists an event-state algebra 
presentation of X 

Proof: Let X = (8\ 2', a \ T '), where 

8' = 6, 2' = 8 , a = A, and t' = {(e.u.ue): e € 8, ue € t}. Then tW) = r,soXis& 
presentation of X I 

Thus we will deal only with event-state algebras from here, with no loss in generality. 

An interpretation from one event-state algebra to another is defined to be any interpretation 
between the embedded event algebras. This interpretation is valid if and only if the interpretation 
between embedded event algebras is valid. 

4.12 Possibilities Maps 

Because we are using states to describe the valid execution sequences of an event-state algebra, it 
is natural to use these states in proving that an interpretation between event-state algebras is valid. 
Capturing execution histories with states allows us to specify valid execution sequences inductively, by 
extending the event mapping of an interpretation to a mapping between state sets, we will give an 
inductive technique for proving that the interpretation is valid. 

The state mappings we will define are somewhat unusual in that we allow a mapping from states 
at the tower level to sets of slates at the higher level. We call these mappings possibilities maps (if they 
satisfy certain properties), because they give a set of possible higher-level states which correspond to each 
lower-level state. Because the states in an event-state algebra can represent any convenient summary of 
execution histories, it is possible that the higher-level state might retain more information about 
executions than the lower-level state. In this case there is not enough information in the lower-level state 
to uniquely determine the higher-level state. Thus we permit "looser" mappings which specify the set of 
states which are consistent with (are "possibilities" for) a given lower-level state. 

Possibilities maps are particularly useful when the lower-level state is distributed, and the 
higher-level algebra is a global interpretation of the lower-level algebra. (It might be convenient to specify 
a distributed algorithm in terms of a "virtual" global state, for example.) Because the tower-level state is 
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partitioned among components, each component has only partial knowledge of the total system state. 
Thus there will generally be several higher-level states which are "possibilities" given the state at an 
individual component. This "partial information" property of distributed systems makes possibilities 
maps a natural tool for describing interpretations of these systems. 

Possibilities maps can be regarded as a generalization of the standard notion of homomorphism. 
The state mapping of a homomorphism is a single-valued function, because the higher-level state space is 
always "more abstract" (has less detailed information) than the lower-level state space. 

If J. x = (6 r Zj, a v Tj) and X 2 = (8 2 , 2 2 , o T t 2 ) are event-state algebras, then we will 
write h: X l - X 2 if h: 6j -► 8* and h: 2j — 9(2 2 ). (We use "h" to denote both the event mapping 
and the state mapping; the meaning will be clear from context.) Note that h: J^ -* J. 2 does not 
necessarily imply that h satisfies any special properties; in particular, h need not be a possibilities map. 
We say that the proper domain ofh (of the state mapping) is: domain(h) = {s € 2 X : h(s) * 0}. 

We extend a mapping h: 2 2 — 9(Z 2 ) to a mapping h: 2j — 3(2^) by defining h^s^ s n >) 

= fctj.ty..., t n >: t; € h( Si ), for i = l,2,...,n}. 

Dcfn 4.12.1: Let X l = (8 p 2 r a v tJ and X 2 = (8 2 , 2 2 , a 2 , r 2 ) be event-state algebras, 
and let h: X 1 -♦ X 2 . We say h is a possibilities ma p iff 

1. h preserves initial states; 
a 2 €h(aj) 

2. h preserves events 

s € PREjfe) n » r t € h(s) n & 2 
=> (t)h(e)€h(se) 

(Note that (t)h(e) € h(se) =» (t)h(e) * ±, since h(se) C 2,.) 



In many cases we will not need the full power of possibilities maps to map from states to sets of 
states. If a mapping h: X^ -> X, has the property that Vs € 2 X , |h(s)| < 1, then we will consider h to 
be a partial mapping from 2 2 to 2 2 , and we will change our notation accordingly. (For example, we will 
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write t = h(s) instead oft € h(s).) 

We will use the properties of possibilities maps to prove inductively that a mapping is valid. As 
an intermediate step, we define the notion of a faithful mapping. We then show the main result for 
possibilities maps: any possibilities map is a valid interpretation. 

Defn 4.2.12: Let ^ = (6 p 2 r a p Tl ) and J. 2 = (8 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: J^ -*• X r For k € X we say that h j§ k-faithful iff ( Vv € tj: |v| < k), 
2 h(v) € h(ajv). We say h is faithful iff h is k-faithful for all k € Jf. Note that h preserves 
initial states if and only if h is 0-faithful. 



Lemma 4.2.2.3: Let ^ = (g^ 2 p CT] , t t ) and M = (6 2 , 2 2 , a,, t,) be event 



state 



algebras, and let h: ^ -* J. r Then h is faithful =» h is a valid interpretation. 

Proof: h is faithful =» a 2 h(v) € h(a x v) Vv € r y Thus a 2 h(v) * ± =» h(v) € t" 2 . I 

Lemma 4.2.14: Let ^ = (6 p 2 r a r Tj) and J^ = (6 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: J^ -*• X^ Then h is a possibilities map => h is faithful. 

Proof: Suppose h is a possibilities map. Then h preserves initial states => h is O-faithful. We 
show h is k-faithful =» h is k + 1-faithful. 

Let ve € tj, |v| = k, e € 8 r Since h is k-faithful, a 2 h(v) € h^v). But ve € TJ =» ffjV € 
PREj(e) (1 «R, r And a 2 h(v) € h(a 1 v) n & 2 . Since h preserves events, a 2 h(v)h(e) € 
hfajve),^ h is k+ 1-faithful. I 

Lemma 4.115: Let X± = (6^ 2 X , a v Tl ) and ^ = (€ 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: U.j -* J^. Then h is a possibilities map =* h is a valid interpretation. 

Proof: Immediate corollary of Lemmas 4.2.2.4 and 4.2.2.3. I 

We will often find it useful to prove preservation of events in two parts: We will assume that 
preconditions are satisfied and show that transitions behave correctly under the interpretation; we will 
show separately that preconditions are satisfied: 
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Lemma 4.2.2.6: Let Uj = (6^ Z r a v Tj ) and J. 2 = (8 2 , Z 2 , a 2 , r 2 ) be event-state 
algebras, and let h: A x -*■ JL Y Then h preserves events if and only if 

1. h preserves transitions: 

s € PRE^e) n »j, t € h(s) D PRE^e)) n & 2 
=> (t)h(e) € h(se) 

2. h preserves preconditions; 

sepRE^n^, t€h(s)n& 2 

=> t€PRE 2 (h(e)) 

Proof: Suppose h preserves events. Then 
s € PRE^e) D » r t € h(s) H » 2 , 
=* (t)h(e) € h(se), 
=» (Oh(e)*_L, 
=» t € PRE^tye)), so h preserves preconditions. 

s € PRE^e) na i( t£ h(s) n PRE 2 (h(e)) n a 2 , 

=> s € PREj(e) n a r t € h(s) n 5b 2 , 

=» (t)h(e) € h(se), so h preserves transitions. 

Conversely, suppose h preserves preconditions and transitions. Then 

s € PRE 1 (e) n % r t € h(s) n 9b 2 , 

=» t C PRE 2 (h(e)), since h preserves preconditions. 
Thus s € PRE^e) H 3b r t € h(s) n PRE^hCe)) n ft 2 , 

=» (t)h(e) € h(se), since h preserves transitions. I 

4.23 Canonical Possibilities Map 

We can show that the method of constructing a possibilities map between event-state algebras is 
a completely general technique for proving validity: Given any (event-homomorphic) valid 
interpretation, an extension of this interpretation to a possibilities map always exists: 

Lemma 4.23.1: Let J^ = (g^ 2 p a v i-j) and X 2 = (S 2 , %, a T r 2 ) be event-state 
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algebras, and h: 6 X -» 8 2 be a valid interpretation from J^ to X^ Then if we extend h to a 
state-set mapping as follows: 

h(s) = {a 2 h(u): op = s} 

then h is a possibilities map from JL Y to JL r 

Proof: First we show that h(s) C 2 2 for all s € 2 X (i.e. ± * h(s)): op = s =» u € fj 

=» h(u) € T 2 (since h is valid) => <r 2 h(u) * JL. Thus h does define a mapping from 2 X to 
9(2 2 ). 

Now we show that h satisfies the conditions for a possibilities map: 

1. h preserves initial states: 

o 2 - ff 2 A = ofiiA) (since h is evcnt-homomorphic); 
a 2 h(A) € (a 2 h(u): op = oj = h^). 

2. h preserves events: 

s € PRE^e) n % v t € h(s) n * 2 . 
Let s = o Y \, \£T r 
So t € h(s) = {a 2 h(u): op = o^}, 
=» t = a 2 h(u) for some u: op - a,v. 

Now (t)h(e) = a 2 h(u)h(e) = a^ue) 
€ {a 2 h(w): o^n - ajve} = h(se). I 

Note that the set h(s) = {a 2 h(u): op = s} corresponds intuitively to the "possibilities" for 
higher-level states associated with lower-level state s: The sequences {u: op = s} are the possible 
histories which might have generated state s; a^u) is the higher-level state that would have resulted 
from execution of u. Thus if we only know state s, then we can only "pin down" the possible higher-level 
state to the set {a^u): op = s}. 
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4.14 Invariants 

We have reduced the task of showing that interpretation is valid to the task of proving that a 
mapping (on both states and events) is a possibilities map. It will often be convenient to use properties of 
reachable states (at both the higher and lower levels) in showing that a mapping is a possibilities map. We 
r generalize the notion of an invariant to include properties of sequences of states as well as properties of 
single states. We also describe properties of individual components of the state, since we will show below 
that if a component is preserved by a state mapping between algebras, then in some cases we can carry 
invariants proved at the higher level for this component downward to the lower level (without re-proving 
the invariants at the lower level). Our development of an event-state algebra hierarchy for a transaction 
system will make extensive use of this method of carrying invariants down from higher level algebras. 

4.14.1 Basic Definitions 

Defn 4.14.1.1: Let X = (8, 2, a, t) be an event-state algebra. If I C Z n , we say that ] is an 
flag property M J* If n = 1, then we will simply say "I is a property," and if n = 2, we will 
say "I is a pair-property." 

Defn 4.14.1.1 Let X - (8, 2, a, t) be an event-state algebra, and let k € X If I is an n-ary 
property in X, we say that 1 is k-invariant in X. iff the following is true: For all sequences 
< v rV- v n> € 1° such that v 2 < v 2 < ... < v n , and |vj < k, we have (ffv 1 ,av 2 ,...,ffv n ) € I. 
We say that J is invariant in A iff Vk € Jf, I is k-invariant in JL Thus I is invariant in X iff 
*l n \x)QL 

We will usually drop the qualification "in X" when the algebra is clear from context Note 
that the case n = 1 corresponds to the usual notion of an "invariant." When we say that "I is 
an invariant," we will generally mean that I is a 1-ary property which is invariant Similarly 
we will say "J is a pair-invariant" if J is a pair-property which is invariant 
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4.2.4.2 Relative Invariants and Relative Possiblities Maps 

To prove that a particular mapping is a possibilities map, we will frequently prove first some 
useful invariants for the higher and lower-level algebras. If we organize a proof hierarchically (with 
several levels of event-state algebras), we might find that we need the same invariants at several of these 
levels. While we could prove the needed invariants independently at each level, to do so might repeat a 
lot of work unnecessarily. Since faithful mappings map reachable states into reachable states, it might be 
easy to infer that higher-level invariants hold at the lower level if we knew that the mapping between 
algebras were faithful. In some cases, however, we might want to use these invariants to show that the 
mapping is a possibilities map (and hence is faithful, by Lemma 4.2.2.4). In these cases we arc faced with 
a mutual dependency between invariants and a possibilities mapping. 

Our solution to this mutual dependency depends on the fact that both invariants and 
possibilities maps are generally proved inductively. Conceptually, then, we will prove both an invariant 
and the possibilities map together with the same induction. For convenience, we separate the 
dependencies in our definitions; we define an invariant relative to a mapping, and a possibilities map 
relative to a property. Because the key property of possibilities maps is faithfulness, we also define 
faithfulness relative to a property, and we prove a lemma which is the "relative" version of Lemma 
4.2.2.4. We also state a "relative" version of Lemma 4.2.2.6. 

Defn 4.2.4.11: Let ^ = (6 r 2 r o y T] ) and JL^ = (6 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: ^ -+ X x Let P C 2 2 be a property in X y 

We say h is a possibilities map relative to P iff 

1. h preserves initial states (a 2 € h(a x )) 

2. h preserves events relative to P; 

s € PREjfe) n fcj D P, t € h(s) D 3b 2 
=► (t)h(e) € h(se) 



Defn 4.2.4.2.2: Let X^ = (8^ Zj, a r T] ) and JL 2 = (8 2 , 2 2 , a 2 , r 2 ) be event-state 
algebras, P C 2 r and let h: JL X -*■ JL T 
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We say h is faithful relative to P iff 

1. h is O-faithful 

2. (Vk € JO h is k-faithful, and P is k-in variant => h is k+ 1-faithful 



Lemma 4.2.4.13: Let ^ = (8 r 2 p o v tJ and J^ - (8 2 , 2 y o 2 , t 2 ) be event-state 
algebras, P C 2 r h: ^ -+ X x If h is a possibilities map relative to P, then h is faithful 
relative to P. 

Proof: h preserves initial state, so h is O-faithful. Now suppose h is k-faithful, and P is 
k-invariant, for some k € Jf. We show h is k + 1-faithful. 

Take v € t^, |v| < k+1. We must show that a 2 h(v) € Ho^). If |v| < k then the result 
follows directly since h is k-faithful, so assume |v| = k+1. Let v = ue, for some u € T v e € 
e x (|u| = k). 

Since h is k-faithful, <r 2 h(u) € Hop). But P is k-invariant, so op € P. Since ue € 1^, op € 
PREjCe). 

Thus op € PREj(e) n » x n P, a 2 h(u) € Hop) H & 2 , 

=» a 2 h(u)h(e) € hfajue), since h is a possibilities map relative to P, 
=> o 2 h(v) € h( 0l x). I 

Lemma 4.2.4.2.4: Let J^ = (8 r 2 r o v Tj) and J^ = (6 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: J. x -*■ J^. Then h preserves events relative to P if and only if 

1. h preserves transitions relative to P; 

s € PREj(e) n gkj n P, t € h(s) n PREjCMe)) n % 2 
=» (t)h(e) € h(se) 

2. h preserves preconditions relative to P: 

s € PREjie) n gb x n p, t € Ws) n a 2 

=> t€PRE2(h(e)) 
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Proof: Similar to the proof of Lemma 4.2.2.6. I 

Dcfn 4.14.15: Let A l = (8 r 2 p o r Tl ) and ^ = (6 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, P C 2 p and let h: J^ -► J^. 

We say P is invariant relative to h iff 

1. P is O-invariant 

2. (Vk€Jf) P is k-invariant, andh isk + 1-faithful ==> P is k -I- 1-invariant 



We now show that we can prove invariants and possibilities maps together with the same 
induction: 

Lemma 4.14.16: Let ^ = (8 1§ 2 r a v rj and Ji 2 = (8 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, P C 2 r Let h be a possibilities map from ^ to -^ relative to P, and let P be 
invariant in J^ relative to h. Then h is a possibilities map, and P is invariant in J^. 

Proof: Since h is a possibilities map relative to P, h is faithful relative to P (by Lemma 
4.2.4.2.3). We show inductively on k that P is k-invariant, and h is k-faithful. P is O-invariant 
and h is O-faithful by definition. Assume P is k-invariant, and h is k-faithful. Since h is a 
faithful relative to P, h is k + 1-faithful. Since P is invariant relative to h, P is k + 1-invarianL 

Thus P is invariant. To see that h is a possibilities map, note that h preserves initial states by 
definition, h preserves events, because 

s € PREj(e) flftj =» s € P since P is invariant I 

4.14.3 Invariants on Fixed Subspaces 

We have described a process for proving an invariant simultaneously with proving a possibilities 
map. In this section we show that this technique can be useful when a particular subspace of the 
lower-level state space is unchanged by the state mapping. 

Defn 4.14.3.1: Let -4. = (8, 2, a, r) be an event-state algebra, let 5 be some index set, and 
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let 2 be the Cartesian product of component sets, r N , for N € 3. We say that N is the name 
of component T N . We assume that each component has a unique name. (We will frequently 
denote a component by a variable name used for an instance of the component set For 
example, if 2 = Tj X T 2 , and we use <A,B> € 2 to represent an instance of the state, then we 
will refer to the "A-component," or the "B-component") Let N p N 2 ... N k be distinct names 
from 3. We say that T N X T N ... X T N is a. subsoace of 2, with name N = <N 1 ,N 2 ,...,N k >. 
(Note that each such composite name denotes a unique subspace.) If s € 2, then "s.N" 
denotes the projection of s onto the subspace named by N. If s = <s 1 ,s 2 ,...,s n > is a vector of 
states, then s.N is defined in the obvious way as <s r N,s 2 .N s .N>. 

We extend the definitions of n-ary properties and invariants to properties which only depend on 
a particular subspace. 

Defn 4.14.3.2: Let A = (g, 2, a, t) be an event-state algebra, and let N name a subspace, 
r, of 2. If I C T n . we say that I is an n-arv property for N. 

Let I be an n-ary property for N, and let I' = {s € 2 n : s.N € I}. We say 1 ]§ invariant fez E 
m£ iff I' is invariant in X If k € Jf, then we say 1 is k-invariant &£ N_ in J, iff I' is 
k-invariant in JL 

Invariants for a subspace are of interest when the state mapping between two algebras fixes that 
subspace. We will show below that invariants for a fixed subspace can be "carried down" to the 
lower-level algebra. 

Dcfn 4.2.4.33: Let X l - (8 r 2 p a v t x ) and J^ = (6 2 , 2 2 , * 2 , t 2 ) be event-state 
algebras, and let h: J. x -* J^. Suppose that the state spaces of JL Y and J^ both contain a 
subspace, T, with name N. We say that fc fijfis H iff for all s € 2 r and for all t € h(s), LN = 
s.N. (Thus h does not change the N-subspace of the state.) It is straightforward to show that 
if h fixes N, s € 2}, and t € h(s), then t.N = s.N. 

Now we show how we can carry higher level invariants for fixed subspaces down to the tower 
level. Because we might want to use these invariants in inductive proofs (in particular, as we explain 
below, in inductive proofs of other relative invariants for the lower level), we state this lemma in 
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"parameterized" form (i.e. in- terms of k-in variants and k-faithful mappings). 



Lemma 4.2.4.3.4: Let X x = (8 r 2 p a v Tj) and X 2 = (8 2 , 2 2 , a y t 2 ) be event-state 
algebras, let k € X, and let h: X 1 -»• X 2 be k-faithful. Let N name subspace T in both 2 X 
and 2 2 , and suppose that h fixes N. If n-ary property I C T n is invariant for N in Xj, then I 
is k-invariant for N in M. 

Proof: Let 12 = {t € 2j: t.N € I}, II = {s € 2j: s.N € 1}. I is invariant for N in X^ so»J n) 
C 12. We must show that that II is k-invariant in X y Let <v 1% v 2 ,...,v n > € tj, with \ 1 < v 2 < 
... v n , and |v n | < k; we show that s = <a 1 v 1 ,a 1 \ 2 ,...,a 1 \ n > € II. Since h is k-faithful, ff 2 n ( v i) 
€ hforjVj) for i = l,2..n. Let t = <<r 2 h(v 1 ),a 2 h(v 2 ),...,ff 2 h(v n )>. Then t € 9b 2 D) , because each 
<r 2 h(v.) € % 2 , and h^) < h(v 2 ) < ... h(v n ) since h is event-homomorphic. 

Since t € 'Hb^, t € 12; thus t.N € I. But t € h(s), and h fixes N, so t.N = s.N. Thus s.N € I, 
=» s € II. I 

Because a mapping which is a possibilities map is necessarily faithful, and hence k-faithful for 
all k, we have the following lemma: 

Lemma 4.14.3.5: Let ^ - (8j, 2 r o v Tj) and X^ = (8 2 , 2 2 , a 2 , t 2 ) be event-state 
algebras, and let h: X^ -* X 2 be a possibilities map. Let N name subspace T in both 2j and 
2 2 , and suppose that h fixes N. If n-ary property I C T n is invariant for N in X^, then I is 
invariant for N in X v 

Proof: Immediate corollary of Lemma 4.2.2.4 and Lemma 4.2.4.3.4. I 



We showed in Lemma 4.2.4.2.6 that if h is a possibilities map from X^ to X 2 relative to property 
P, and P is invariant for X l relative to mapping h, then it follows that h is a possibilities map. Because of 
Lemma 4.2.4.3.4, we can use known invariants for fixed subspaces in X^ to prove that P is invariant 
relative to h. Note that in proving that P is invariant relative to h, we can assume that h is k+I-faithful 
(instead of simply k-faithful) when showing P is k+1-invariant. By Lemma 4.2.4.3.4, we can thus assume 
that invariants from X 1 for fixed subspaces are k+1-invarianL 

We will generally apply Lemma 4.2.4.3.4 to 1-ary or 2-ary invariants. We summarize the 
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(s.N, LN) € J 

=» t € P (by the Induction Hypothesis of the Lemma), 

=» P is k+l-in variant I 



It is important to understand exactly what Lemma 4.2.4.3.6 says: We cannot assume that the 
higher-level invariants (I and J) are truly invariant in X^ but we can assume they are k-h I -invariant for 
the induction step of showing P invariant Because we construct the induction so that faithfulness of h 
stays "one step ahead" of invariance of P, we can assume both tN € I, and (s.N,tN) € J above. (If we 
only knew that h were k-faithful, instead of k+1-faithful, then we would only be able to assume s.N € I.) 

4.2.5 Augmentation Maps and Auxiliary State 

ITie power of possibilities maps to map a single state into a set of states is useful when the 
lower-level algebra is somehow "more abstract" than the higher-level algebra. If the higher-level model 
retains more information about a system than a lower-level model, then the low-level state will not 
uniquely determine the high-level state. Another technique for showing a valid interpretation from one 
algebra to another is to augment the lower-level state with auxiliary variables. These variables are 
"virtual" components of the state, in that they do not enter into any preconditions for events, and the 
transition effects on other components of the state are not affected by the auxiliary variables. 

Dcfn 4.2.5.1: Let ^ = (S 2 , ^ „ y T] ) and A 1 = (6 2 , 2 2 , a 2 , t 2 ) be event-state algebras. 
We say that J^ is an augmentation of ^ with auxiliary state f\m ifr 



1. 8 2 = 6l 

2. 2 2 = 2j X Aux 

3. a 2 = (e v a^ for some a,, € Aux 

4. Ve € 8j, PRE^e) = PREj(e) X Aux (i.e. the auxiliary state enters into no 
preconditions) 

5. (s,a) € PRE^e) -» r 2 (eXs,a) = (r^eXsXa') for some a' € Aux (i.e. the 
auxiliary state does not affect transitions) 
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If X 1 is an augmentation of X x with Aux, then we define the au gmentation map , h: X x -*■ 
Xp as follows: 

Ve € 6 r h(e) = e 

Vs € 2 r h(s) = {s} X Aux. 

Lemma 4.2.5.2: Let X x = (6^ 2^ a v Tj) and X 2 = (8 2 , 2 2 , a 2 , t 2 ) be event-state algebras, 
and let X 2 be an augmentation of X x with auxiliary state Aux. Then 2 X is a subspace of 2 2 , 
and the augmentation map, h, fixes 2,. 

Proof: Straightforward from the definition. I 

The following lemma shows a relationship between the technique of using auxiliary state, and 
the technique of defining a possibilities map: every augmentation map is a possibilities map. 

Lemma 4.2.5.3: Let X 1 = (8 r 2 1? a v tJ and X 2 = (8 2 , 2 2 , a 2 , r 2 ) be event-state algebras, 
and let X 2 be an augmentation of X x with auxiliary state Aux. Then the augmentation map, 
h, is a possibilities map. 

Proof: 

1. hioj = {(apa): a € Aux}, 

=> lo v &^ e hCffj). 

2. Let s € PREjfe) n » r t € h(s) n «*> 2 , 
=» t = (s,a) for some a € Aux. 

s € PRE^e) -» (s,a) € PRE^e)) = PRE^e), 
=» (t)h(e) = te = r 2 (cXt) = (TjteXsXa') for some a'. 
But h(se) = {(se,a): a € Aux} = {( Tl (eXs),a): a € Aux}, 
=> (t)h(e)€h(se). I 
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4.3 Distributed System Model 

We model a distributed system as a special type of event-state algebra. First we present a 
general framework for a "distributed algebra," and then we specialize further to a particular model for the 
distributed environment of our transaction system. While these models have considerably more structure 
than an arbitrary event-state algebra, it is important to note that they can still be described as special cases 
of event-state algebras. Thus we can apply our results for possibilities maps and invariants directly to 
these distributed algebras. 

4.3.1 Distributed Event-State Algebras 

Defn 4.3.1.1: Let J. = (8, 2, a, r) be an event-state algebra, let I be a finite index set, and 
let orig be a mapping orig: 6-1. We say that A is distributed over I using ojjg provided 
that the following are true: 

a. 2 is the Cartesian product of sets 2 j5 for i € I. We will use index i as the 
component name for set 2.. 

b. a is a vector of initial states, a € 2., for i € I. 

c. For each i € I, there is a local transition relation r i C 6 X 2. X 2.. t. must 
satisfy the following "local precondition" property: If e € 6, s € 2 4 , and orig(e) 
* i, then TjteXs) * _J_. Then t is determined by the local transition relations as 
follows: t = {(e,s,t): (e,s.i,Li) € r v Vi € I}. 

If orig(e) = i, men we say that component i is the originator of event e. 

Because the transition relation of a distributed event-state algebra is defined by combining local 
transition relations for each component, the effect of each event on a component depends only on the 
current state of that component. It is possible for an event to affect several components, however. (Thus 
we are permitting an arbitrary "interconnection" of components through events.) 

Although an event can have effects at several components, its precondition must be local to its 
originating component Only the originator can control when one of its own events can occur. 
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In [Lynch82], a "local mapping" technique is explored for constructing a possibilities map from 
a distributed event-state algebra to another event-state algebra; the possibilities map is defined as the 
intersection of local possibilities maps from the states of all components in the distributed algebra. 

4.3.2 Message-based Distributed Algebras 

We now restrict distributed event-state algebras further to model the particular distributed 
environment of this thesis. The basic system components are nodes, with local state spaces and local event 
sets. All communication between nodes must flow through a disunguished system component, the 
message buffer. We define disunguished send and receive events for communications through the 
message buffer. 

We give the message buffer a specific semantics: Wc postulate that messages are delivered in 
arbitrary order after they are sent, and that they can arrive any number of times (including 0) after they 
are sent. These assumptions allow us to model the message buffer as a set of messages (the set of all 
messages ever sent). It is never necessary to remove a message from this set, because we assume that 
messages can be duplicated and delayed arbitrarily. 



Defn 4.3.2.1: Let J. = (8, 2, a, t) be an event-state algebra distributed over I using orig. 
Let Nodes be a finite set of nodes, let Msgs y be a set of messages from node i to node j (ij € 
Nodes), and let Msgs = U Msg SjJ . We say that J, is a message-based algebra ovgr. Nodes 
USing MsgS if the following arc true: 



a. I = Nodes U {buf}, where "buf ' names the message buffer component 

b - ^buf = ^Msss) 0- e - ^ message buffer is a set of messages). Let BUF = \ r 

c. a.buf = (the message buffer is initially empty; thus no message can be 
received before it is sent). 

d. Let Comm = {send M: M € Msgs} U {receive M: M € Msgs} be the set of 
communications events. Then Comm £ 6. If M € Msgs. ., then orig(scnd M) = i, 
orig(receive M) = buf: The originator of a send event is the source node for die 
message, and the originator of a receive event is the message buffer. (We regard the 
destination node for a message as passive in the communications process.) 
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e. If e € 6 - Comm, and i * orig(c), then iv(e) is the identity on 2 r Thus all "local" 
events (events not in Comm) must have only local effects. (Note that preconditions 
must be local by the definition of a distributed algebra). 

f. If M € Msgs^, then r k (send M) is the identity on 2 k , for k * buf,i. r^send M) 
C {(a,a): a € 2j}. Thus although the sender of a message imposes a precondition 
on the sending of a message, the send has no effect on the sender's state. 

g. T bu( (send M) = {(b, b U {M}): b € BUF}. Thus the effect of a send event on 
the buffer is to add the message to the buffer. 

h. T k (receive M) is the identity on 2 k , for k * j.buf. Tj (receivc MXa) * _L, Va € 
2j. Thus receipt of a message affects the state of the receiver, but the receiver 
cannot impose a precondition on receive events. (The originator of a receive event 
is the message buffer.) 

1 7 W rcccive M > = K b ' b ) : b € BUF A M € b}. Thus a receive event for a 
message can occur whenever that message is in the buffer. A receive event has no 
effect On the state of the message buffer, however. (Messages are never removed). 

We stress that the message semantics we have chosen is not inherent in the distributed algebra 
framework; this semantics is simply convenient for describing our system. Our message-based model 
could be changed easily to provide for different communications semantics. For example, we could 
model a "reliable" communications system by making the message buffer an ordered list of messages, 
which only delivers messages from the head of the list and removes them upon delivery. 
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5. Proof Strategy 

In the following chapters we will specify several levels of an event-state algebra hierarchy; these 
algebras model a distributed transaction system. The algebras are presented in top-down order: the 
top-level algebra (Level 0) is the "most abstract," and the bottom-level algebra (Level 7) is the "most 
concrete." At each level we specify the state, the initial state, the events, and the transition relation. At 
each level (except Level 0) wc also specify a mapping from the new level to the previous (higher) level, 
and we show that this mapping is a possibilities map. 

Our goal is to show that the orphan detection strategy which we outlined in Chapter 1 
guarantees view-serializability. Thus our top-level model specifies our "correctness condition:" The 
Level state is just the set of all action trees, and we define simple events to create, commit, and abort 
actions, and to perform an access. The only preconditions at Level require that each state generated by 
any event be view-serializable. 

At Level 1 we add a data ordering to the state (thus states are now augmented action trees). We 
impose preconditions on events to restrict the reachable states to view-serializable AATs. We define the 
set of aborts "depended on" by an action; as one of our preconditions we require that each state 
generated by any event satisfy condition ANC- ABORT - no action can depend on an abort of one of its 
ancestors. We then show that all reachable AATs in Level 1 are view-serializable. Thus the obvious 
mapping from Level 1 to Level is a possibilities map. 

At Level 2 we remove the ANC- ABORT condition by adding a precondition to perform events. 
This precondition essentially states that an access should not see an abort dependency on an ancestor at 
the time it is performed. We show that the reachable states in Level 2 satisfy ANC-ABORT (using this 
new precondition); thus the obvious mapping from Level 2 to Level 1 is a possibilities map. We refer to 
this precondition as the "orphan detection" precondition. 

Levels - 2 are global state algebras, in that we regard the transaction system as operating on a 
single global state. These levels can be thought of as "centralized" interpretations of the events in a 
distributed action system. Lower levels progressively "distribute" this global state and localize the 
preconditions and effects of events. 

At Level 3 we introduce locations," which can be thought of as abstract nodes. Each action and 
each object has its own location. The information at a location consists of a (local) unlabeled action 
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summary, plus the datastep ordering from the AAT. We define very simple "communications" events to 
transfer information to any location. We show that it is relatively simple to localize all preconditions 
except for the orphan detection precondition. The orphan detection condition must still be expressed in 
terms of the global AAT. The implication of this result is that our communications steps at Level 3 do not 
include enough information to completely localize orphan detection. 

At Level 4 we introduce value maps -- a data structure which models the locks and versions of 
atomic objects. The Level 4 state consists of an AAT, a "local state" mapping from locations to UAS's, 
and a value map for each object. We regard the value map as a local data structure (conceptually each 
object has its own value map.) We replace some of the preconditions on perform events with 
preconditions on value maps, and we modify the transition effects' of actions to update value maps 
appropriately. 

At Level 5 we succeed in localizing the orphan detection precondition by piggybacking abort 
information on the create and commit communications events. This abort information models the 
DONE lists of our simplified orphan detection algorithm. The key invariant proved for I^vel 5 states 
that each location always has "enough" abort information. 

Because all preconditions are localized at Level 5, the global AAT can be regarded as a "virtual" 
component of state. We project out this global state at Level 6, and we construct a trivial augmentation 
map between Level 6 and Level 5. Although the resulting algebra is "localized," it does not quite fit our 
definition of a "distributed" event-state algebra. To define a distributed event-state algebra, we must 
assign "locations" (abstract nodes) to physical nodes. An additional complication results from the 
simplicity of our communications events at Levels 3 - 6: The transfer of information caused by these 
events is considered instantaneous at these levels. For a distributed event-state algebra we must model 
arbitrary communications delays. 

Level 7 presents a distributed event-state algebra. Many actions and objects can reside at a 
single node, and messages are sent asynchronously via a message buffer. In mapping from Level 7 to 
Level 6, we account for the communications delays in the message buffer by considering messages 
themselves to be abstract "locations." (One way to think of this device is to imagine that at Level 6 we 
can consider all communication events to be instantaneous, but all messages are seat via a third party. At 
Level 7, we "know" that this third party is really the message buffer, but at Level 6 this detail is not 
necessary.) 
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6. Global State Models 

This chapter presents Levels - 2 of the event-state algebra hierarchy. Level describes our 
correctness condition: every action tree generated by the system must be view-serializable. Level 1 is a 
global state model based on AATs. Level 1 develops the crucial link between view-serializability and 
orphan detection: We define the "aborts dependency set" for an action in an AAT, and we require at 
Level 1 that no action can depend on an abort of one of its ancestors. Informally this condition, which 
we call ANC-ABORT, means that no action can "know" that it is an orphan. At Level 1 we show that the 
ANC-ABORT condition (along with other preconditions on events) implies view-serializability. 

The ANC-ABORT condition is imposed at Level 1 by requiring that the next state generated by 
each event satisfy ANC-ABORT. At Level 2 we replace this restriction with a single precondition on data 
accesses, and we show that this precondition suffices to guarantee ANC-ABORT. 

We also make use of an auxiliary algebra, which we call "Level A" (denoted La). Level A 
consists of Level 1 without the ANC-ABORT restriction. Thus Levels 1 and 2 are both logically "below" 
Level A. The advantage of using this auxiliary level is that we can easily construct a possibilities map 
from Level 2 to Level A; we will then use Level A invariants in showing that there is a possibilities map 
from Level 2 to Level 1. 

We will use the following distinguished symbols to define the initial states of the algebras: 

T denotes the trivial AAT containing only vertex U with status 'active', and an empty data ordering: 

verticesy = {U} 
statu&j. (U) = 'active' 
label,. = 
dataj. = 



Tj = erasefTo) (an action tree), and T u = unlabelfTj) (a UAS). 
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6.1 I^cvcl Algebra 

The Level state consists of a (global) action tree. The events at Level are just those needed to 
create an action tree: we define events to create an action, commit and abort an action, and perform an 
access with a given value (this value gives the label of the datastcp in the action tree). The only constraint 
on validity of an execution sequence at Level is that the resulting action tree must be view-serializable. 



L0= (g^ff^T,,) 

6 fl = {create A, commit A, abort A, perform A,u} (see below). 

2 Q is the set of all action trees. 

a Q = Tj, the trivial action tree. 

Tq, the transition relation, is specified below via preconditions and transition effects for each event: 

Let the current state be T. For each event, we give the transition function which maps T -*• Tl. The 
precondition for each event is a logically a condition on T, the current state, but we specify it as a 
condition on Tl. (Since T uniquely determines Tl, a condition on Tl maps directly into a condition on 
T.) The single precondition for each event requires that the next state (Tl) be view-serializable. Let VSR 
denote the set {T: T is a view-serializable action tree}. 

1. create A (A€act-{U}) 
PRECONDITIONS: 

a. Tl € VSR 
TRANSITIONS: 

a. verticesjj «— vertkeSy U {A} 

b. statuSy^A) +- 'active' 

2. commit A (A € act - {U} - accesses) 
PRECONDITIONS: 
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a. Tl € VSR 
TRANSITIONS: 

a. status^A) ♦- 'committed' 

3. abort A (A€act-{U» 
PRECONDITIONS: 

a. Tl € VSR 
TRANSITIONS: 

a. statu&p^A) ♦- 'aborted' 

4. perform Aji (A € accesses^), u € values(x)) 
PRECONDITIONS: 

a. Tl € VSR 
TRANSITIONS: 

a. statuSp^A) +- 'committed' 

b. label T1 (A) <- u 



The following lemma justifies our statement that LO defines our correctness condition, because 
all reachable states in LO are view-serializable action trees. 

Lemma 6.1.1: Let T € \. Then T € VSR. 

Proof: Let T = T.v, for some v € ^. If v * A, then T = Te for some e € 6 , T € PRE^e), 
and by the VSR precondition for e, T € VSR. If v = A, then T = T, which is trivially in 
VSR. I 



-81 



6.2 Level 1 Algebra and Mapping h 10 

The Level 1 state consists of a (global) A AT. The events are identical to those defined at Level 
0, but we modify the preconditions as we begin to specify in detail how the transaction system functions. 

LI = (gj.Sj.aj.Tj) 

S x = 8 = {create A, commit A, abort A, perform A,u}. 

2 1 is the set of all augmented action trees. 

a 1 = T Q , the trivial AAT. 

Tp the transition relation, is specified below via preconditions and transition effects for each event 

We will define a condition, ANC-ABORT, on AATs, which essentially states that an action 
cannot know that it is an orphan. We include a precondition for each event in LI which requires that the 
next slate generated by this event must satisfy ANC-ABORT. It will follow trivially that ANC-ABORT is 
satisfied by all reachable states in LI. 

6.2.1 Aborts Dependencies and Condition ANC-ABORT 

We want to develop a condition which will rule out execution sequences in which orphans see 
"inconsistent" data. To devise a condition which can distinguish "bad" orphans from orphans which are 
not dangerous, we define the set of aborts upon which an action "depends." The ANC-ABORT 
condition simply states that an action cannot depend upon the abort of any of its ancestors. 

Informally, an action depends on any abort which allowed the action to proceed. Because of 
sequential dependencies, any abort of a sequentially preceding sibling is depended on by its following 
siblings and their descendants. A parent also depends on the aborts of any of its children. Any abort 
which "releases a lock" on an object subsequently read by an action is depended upon by that action. 
Our Level 1 model does not have explicit "locks"; locks and versions are represented by the entire action 
tree. (Precondition PI .4b below is essentially a "lock" condition which says that two actions (at any level) 
cannot interfere on the same object: one must either commit or abort before (he other is allowed to 
proceed. Precondition PI .4c is essentially a "current version" condition which says that the current 
version seen by a datastep is the result of all preceding accesses which are visible to it) 
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An action also depends on all the aborts depended on by committed actions which might pass 
information to it (which for our purposes will be considered all the actions in its view set). Thus the 
aborts dependency set for an action is defined as the union over all actions in its view set of the 
"immediate aborts" preceding those actions. 

Defn 6.2.1.1: Let T be an A AT, A € vertices.,.. We define the aborts dependency sei of A in 
1 as follows: 

ABORTS -^A) = Ui-precedesJB) 
1 B t vset^A) ' 

We define the set ANC-ABORT as the set of all AATs in which no action depends upon the 
abort of an ancestor: 

Defn 6.11.2: ANC-ABORT = {T: VA € vertices anc(A) fl ABORTS^A) = 0}. 

We also define a "sequential aborts set" which represents all the aborts upon which an action 
depends when it is first created. 

Defn 6.11.3: Let T be an AAT, A € verticesp We define the sequential aborts dependency 
S£t fif A in 1 as follows: 



SEO-ABORTSt /A) = i-anc-seq^A) U U ABORTS^B) 
1 l B € v-anc-sa^A) 



The following lemma relates the sequential aborts set of an action to the sequential aborts set of 
its parent: 

Lemma 6.11.4: Let T be an AAT, and A € verticeSp If A * U, then 

SEQ-ABORTS 1 <A)=SEQ-ABORTS 1 <parent(A))U IjABORTS^B) U i-seq^A). 

AndSEQ-ABORTS^U) = 0. 

Proof: It is obvious that SEQ-ABORTS^U) = 0. Take A * U. By definition of 
SEQ-ABORTS, 



SEQ-ABORTS^A) = i-anc-seq^A) U UaBORTWB) 
1 l B t v-anc-seqrCA) 
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But i-anc-seq^A) = i-seq-^A) U i-anc-seq^arentfA)), and v-anc-seq^A) = v-seq^A) U 
v-anc-seq^arentCA)). Thus 

SEQ-ABORTS^A) = i-seq^A) U i-anc-seq^parenKA)) U U ABORTS^B) U 

Uabortmb) . 

B € v-anc-seq-j<parent(A)) 
= SEQ-ABORTS^parenKA)) U UABORTS^B) U i-seq^A). I 

The following lemma relates the flow of information via view sets to the flow of abort 
information via ABORTS sets: 

Lemma 6.2.1.5: Let T be an AAT, A € vertices p B € vsetj<A), then 

ABORTS T (B)C ABORTS^A) 

Proof: ABORTS^A) = Ui-prccedes^C) , while ABORTS^B) = Ui-precedes^C) . 

But if B € vsetj{A), then vset^B) C vset^A) by Lemma 2.3.3a. The lemma follows directly. 
I 

The definition of view sets as the closure under v-precedeSj. allows us to write a recursive 
expression for ABORTS^ 

Lemma 6.2,1.6: Let T be an AAT, A € verticesp then 

ABORTS^A) = i-precedeMA) U UaBORTS^B) 

B € v-preoeAsj/A) 

Proof: vsetpCA) = {A} U v-precedes^A) 

= {A}U UvseUB) 

B t v-pretedcs^A) 

The Lemma follows directly. I 

Since action trees are always finite, we can use this recursive form in inductive proofs of 
properties of aborts sets if we show that tracing back the v-precedes,. relation will not result in cycles, Le. 
mat VA € verticesp A t v-precedes^(A). (If v-precede^ were acyclic, then the induction might not be 
well-founded.) We will prove below that v-precedeSy is acyclic for all reachable trees in La (and hence 
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for all reachable trees in LI). 

6.2.2 Specification of Event Preconditions and Transitions for LI 

Let the current state be T. For each event, we give the the transition function which maps T -»• 
Tl. Preconditions are specified as a function of T, except for the ANC-ABORT condition which requires 
that the next stale be in ANC-ABORT. 

1- create A (A€act-{U» 

PRECONDITIONS: 

a. AC vertices^. 

b. parent(A) € activej 

c. <B,A) € seq, B * A => B € donej. 

d. Tl € ANC-ABORT 
TRANSITIONS: 

a. verticesj-j «— vertices^- U {A} 

b. status^ A) «- 'active' 

2. commit A (A € act - {U} - accesses) 

PRECONDITIONS: 

a. ACactivej 

b. children^A) C donej 

c. Tl € ANC-ABORT 
TRANSrriONS: 

a. stattiSj-jfA) «- 'committed' 
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3. abort A (A€act-{U» 
PRECONDITIONS: 

a. A € activej. 

b. Tl € ANC-ABORT 
TRANSITIONS: 

a. status^A) ♦- 'aborted' 

4. perform A.u (A € accessed x), u € values(x)) 
PRECONDITIONS: 

a. A € activej 

b. B € datastcps^x) =» B € visible^ A,x) V B € dead,<A,x) 

c. u = result(x,s), where s = «visible T (A,x); data T » 

d. Tl € ANC-ABORT 
TRANSITIONS: 

a. statu&j-^A) ♦— 'committed' 

b. labelj-^A) +- u 

c. data T1 <- dataj U {(B,A): B € datasteps^x)} U {(A,A)} 



6.2.3 Specification of Mapping h 10 

We define the mapping h 1() : LI -* LO in the obvious way. Our goal, of course, is to show that 
this mapping is a possibilities map. 

State Mapping 

h lfl : 2 X -* 2 fl is defined by h 10 (T) = erase(T), VT € Sj. 

Event Mapping 
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h ]Q : 8, -* 8 is the identity map on events. 

6.2.4 Proof Strategy for Showing h ]0 is a Possibilities Map 

We can show easily that h,„ preserves initial states and transitions: 

Lemma 6.2.4.1: h, Q preserves initial states. 

Proof: h 1() (T ) = erasc(T ) = T, by definition. I 

Lemma 6.2.4.2: h 10 preserves transitions. 

Proof: It is obvious by inspection that h ]Q preserves transitions, since transitions for all events 
are identical at levels LO and LI (except for transition T1.4c, which involves the data ordering 
- but data T is projected out by the state mapping). I 

Showing that h ]Q preserves preconditions is more difficult. Wc use the following lemma to 
reduce this problem to a view-scrializability condition on reachable states in LI: 

Lemma 6.2.4.3: Suppose that for all T € % v T is view-serializable. Then h 10 preserves 
preconditions. 

Proof: To show that h lfl preserves preconditions, we must show that 

T € PREjCe) n % v h 10 (T) € <*> => h 10 (T) € PRE (h 10 (e)). 

But the only precondition at Level is that the next stale must be in VSR. Thus 
h 10 (T) € PRE fl (h 10 (c)) ~ h 10 (T)h 10 (e) € VSR. 

Since h preserves transitions, h ]0 (T)h 10 (c) = h ]0 (Te) = erasc(Tc). Thus we must show that 
erase(Te) € VSR. Since view-scrializability of AATs is defined to be view-scrializability of 
the corresponding action tree, wc must show that 

T € PREj(e) D % y crasc(T) € 5> =» Tc is vicw-serializablc. 

But T € PREj(e) D < % 1 =* Te € 9> y Thus it suffices to show that all reachable states in LI 
are vicw-serializablc. I 



-87 



View-scrializability of reachable states is thus our main theorem for 1.1, which will imply that 
h 1Q preserves preconditions (and is thus a possibilities map). We state this theorem here, although its 
proof will be given in several stages: 

Theorem 6.2.4.4: Let T € % y Then T is view-serializable. 

The proof of this theorem consists of showing that for each action A € vcrticcs. r vtree T (A) is a 
serializable view tree for A. The proof that S = vtree..(A) is a serializable view tree is given in three 
subordinate lemmas which show that (1) S is a view tree for A in T, (2) S is version-compatible, and (3) 
there are no cycles (of length 2 or greater) in seq s U sibling-data s . By Theorem 2.5.1, it follows that S is a 
serializable view tree for A. We state these lemmas here, although the proofs are deferred to later 
sections. 

Lemma 6.2.4.5: Let T € &,. let A € vertices,., and let S = vtree T (A). Then S is a view tree 
for A in T. 

Lemma 6.2.4.6: Let T € c $> v let A € vertices p and let S = vtree r (A). Then S is 
version-compatible. 

Lemma 6.2.4.7: Let T € % v let A € vertices^-, and let S = vtree T (A). Then seq s U 
sibling-data s has no cycles of length two or greater. 

6.3 Auxiliary Algebra La 

We define an "auxiliary" event-state algebra, La. (La is "auxiliary" because it is not part of our 
main event-state algebra hierarchy.) La is identical to LI, except that the ANC-ABORT preconditions on 
events (preconditions Pl.ld, P1.2c, P1.3b, and P1.4d) arc omitted. 

We define the trivial mapping h ]a : LI -* La as the identity map on states and events. 

Theorem 6.3.1: h la is a possibilities map. 

Proof: Since initial states are identical in LI and 1^, and h la is the identity on states, h^ 
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preserves initial states. • Since all transitions and preconditions in Level 1 also appear at Level 
A, h, must preserve transitions and preconditions. Thus h ]a is a possibilities map, by Lemma 
4.2.2.6. I 

Since this mapping fixes T (it must fix T since T is the entire state), we will show that all invariants (and 
pair-invariants) for La are invariant (or pair-invariant) for LI. 

We prove below several basic lemmas for algebra La. We will then apply these results to the 
proofs of Lemmas 6.2.4.5, 6.2.4.6, and 6.2.4.7. 

The advantage of defining La is that we will also construct a trivial possibilities map between 
algebra L2 and algebra La. We will thus be able to apply Level A invariants directly to Level 2, and we 
will use these invariants to show that h 21 (defined below) is a possibilities map. 

6.3.1 Basic Lemmas for La 

6.3.1.1 Invariants and Pair-lmariants for La 

Lemma 6.3.1.1.1: Let (T,T1) € % t2 \ and let A € vertices T . lhcn the following are true: 

a. verticeSy C vertices^, committedj- C committed^, aborted^- C aborted^, 

data r C data T1 

b. If A € datasteps-j, then label r (A) = label T1 (A) 

c. If A € datastepSj and (B,A) € data n , then (B,A) £ datay 

d. visiblc T (A) C visible T1 (A) 

e. deadj(A) C deady^A) 

f. If A is live in Tl, then A is live in T 

g. If A is dead in T, then A is dead in Tl and {crucial TJ (A)} < {crucial T (A)} 
h. v-anc-seq T1 (A) = v-anc-seq T (A), i-anc-seq T1 (A) = i-anc-seq^A) 

Proof: Straightforward. I 

Lemma 6.3.1.1.2: Let T C 9i> a . Then the following invariants hold: 
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a. T is an AAT, i.e. A € vertices,. =» parcnt(A) 6 vcrtice&j- 

b. If A € vertices, and (B,A) € scq and B * A, then B € doney 

c. If A € vertices.,, and parent(A) € committed,-, then A € done T 

d. U € active T 

c. If (B,A) 6 data,, then B € visible,.(A) V B € dead^A) 

f. If A € committed, and B € desc(A) (~\ vcrticeSp then B € visible^A) V B € 

deadj(A) 

g. If (B,A) € i-data,.. tlicn crucial,(B) is defined, and cmcial T (B) € desc(A|B) 

Proof: All are obvious except for (e) and (0 ((g) follows directly from (e)): 

e) If B = A then the result is immediate. If B * A, then 

Let T = T v, where v € V^ can be written as (pw^, with m = perform A,u. 
Let Tl = T Q <p, and let T2 = T <p7r. 

By Lemma 6.3.1.1.1c, (B,A) € data )2 =» B € datasteps,-,(x). By precondition Pa.4b for 
perform, B € visibIe T1 (A,x) V B € deadj-^A.x). 

B € visible T] (A,x) =» B € visible,(A,x) (by Lemma 6.3. 1.1. Id), =» B € visible^A). 

B € dead^A.x) => B e dead,(A,x) (by Lemma 6.3.1.1.1e), ^ B € dead f (A). 

If B = A, then the result is immediate. So assume B € prop-dcsc( A), and assume B * 
visible^A). Let C € prop-dcsc(A) fl anc(B) be the highest ancestor of B which is not 
committed. Then parcnt(C) € committed, => C € done,, (by Lemma 6.3.1.1.2c). But C $. 
committedj by assumption =» C € aborted^ I 

Lemma 6.3.1.1.3: Let (T,T1) € Ik , and let A € committed... Then the following are true: 

a. children T ,(A) = children^ A) 
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b. v-child ri (A) = v-child T (A), i-child n (A) = i-child^A) 

c. v-data ri (A) = v-data^A), i-data 1] (A) = i-data^A), 

v-data-anc n (A) = v-data-anc r (A) 

d. i-data-anc j.^A) < i-data-anc T (A) 

e. v-prcccdes ri (A) = v-prccedes r (A), vsctj-^A) = vset..(A) 

f. i-prcccdes 11 (A) < i-prccedcs^A) 



Proof: 



a) Clearly childrcn T (A) C children r ( A). Suppose B € children T1 (A) - children-j-(A). (We 
can assume A <£ accesses.) 

Let Tl = T v, where v € X can be written as tpinppy, with w = commit A, p = create B. 
LetT2 = 7 Q tpwif>. 

Then A € committed^. But precondition Pa.lb requires that A € active,.,, a contradiction. 

b) Follows directly from (a) and Lemma 6.3.1.1.1d 

c) Because any datastcp which occurs after perform A,u must follow A in the data ordering, 
v-data ri (A) U i-data n (A) = v-data^A) U i-data^A). But i-data^A) C deadj(A) by 
Lemma 6.3.1.1.2c, and dcadj/A) C dead ri (A) by Lemma 6.3.1.1.1e. Thus i-data^A) C 
i-dataj^A). 

But v-data r (A) C v-data n (A) by Lemma 6.3.1.1.1d. It follow directly that v-data^A) = 
v-dataj-^A), and i-dataj.(A) = i-dataj-^A). Equality of v-data directly implies equality of 
v-data-anc. 

d) Follows directly from (c) and Lemma 6.3.1. l.lg 

e) Equality of v-precedes T1 (A) and v-prccedcs^A) follows directly from parts (b) and (c) 
and from Lemma 6.3.1.1. lh. To show that vsetj^A) = vset^A), we can argue inductively 
since B € v-precedes^A) =» B € committed^, by Lemma 2.3.2. 

Follows directly from parts (b) and (d) and from Lemma 6.3.1.1.1h. I 
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Lemma 6.3.1.1.4: Let T £ % , A € committed^ Then i-precedes^A) C abortedj.. 

Proof: Let B € i-precedes^A). 

B € i-anc-seq T =» B € done T by Lemma 6.3.1.1.2b, =» B € abortedj (since B $ 
visible T (A)). 

B € i-childy => B € done T by Lemma 6.3.1.1.2c, =» B € abortedj- (since B £ 
visible 1 (A)). 

B € i-data-anc T =» B = crucial T (b), for b € i-data^A). By Lemma 6.3.1.1.2g, B is 
defined, => B € abortedj-. I 

6.3.1.2 Event Orderings in La 

This section presents some constraints on the ordering of events in valid execution sequences for 
La. In the following lemmas (and in the proofs that follow) we will simplify our notation by referring to 
both "perform A,u" events and "commit A" events as "commit A." This convention causes no 
complications; it requires only that we realize that events written as "commit A" might refer to datasteps. 

Lemma 6.3.1.2.1: Let v € V be a valid execution sequence from l^a, then -» is acyclic -- i.e., 
no event can be repeated in a valid execution sequence. 

Proof: Suppose event e could be repeated in a valid execution, v, i.e. v = a'e^cc € Y. 
LetTl = T ae,T2 = T Q aeb. By Lemma 6.3.1.1.1, 

e = create A => A € vertices^, 
e = commit A =» A € committed^, 
e = abort A => A € aborted^. 

But by the preconditions for events, 

e = create A requires A £ vertices^ (Pa.la). 

e = commit A requires A € active™ (Pa.2a and Pa.4a). 

e = abort A requires A € active^ (Pa.3a). 

Thus no event can be repeated. I 
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Lemma 6.3.1.2.2: Let v € X , T = T Q v, A € committedp then 



create A -* commit A 



Proof: v can be written as <pw^, with w = commit A. 
LetTl = T «p. 

Precondition Pa.2a (or Pa.4a if A € accesses) requires A € active-^, 
=> create A € <p, 
=» create A -+ commit A. I 



Lemma 6.3.1.2.3: Let v € X ', T = T n v, A C abortcd T , then 

a 1 



create A -+ abort A 



Proof: Similar to the proof of 6.3. 1.2.2 above. I 

Lemma 6.3.1.2.4: Let v € r , T = T Q v, (B,A) € data p B * A, then 

commit B -+ commit A 

Proof: v can be written as tpir^, with w = commit A (= perform A,u). 
LetTl = T <p, and let Yl = T 9«r. 

By Lemma 6.3.1.1.1c, (B,A) € data^, 
=» B € committedj.j, 
=» commit B -* it ( = commit A). I 

Lemma 6.3.1.2.5: Let v € r , T = T Q v, A € datastcpSp B € v-data^A), then 

commit AJ.B -+ commit A 

Proof: A € datastcps r =» commit A C v. 

Thus v can be written as tpinp, with v - commit A (= perform A,u). 

LetTl = T «p,andletT2 = T Q <pv. 



93 



By Lemma 6.3.1.1.1c, (B,A) € data ]2 . 

By Lemma 6.3.1.1.2e, B € visible T2 (A) V B € dead^A). 

If B € deadj- 2 (A) then B € dead r (A), ==> B C visible T (A), a contradiction. 

Thus B € visible^A), 
=> AJ.B € committed r2 , 
=> commit AjB € <p, 
=» commit AjB -^ commit A. I 



Lemma 6.3.1.2.6: Let v € "T, T = T Q v, A € vertices r , A' € prop-anc(A) - {U}, then 



create A' -* create A 



Proof: A € vertice&j. => create A € v. 

Thus v can be written as qpw^, with ir = create A. 
LetTl = T Q qp, and letT2 = T <pw. 

By precondition Pa.lb. parcnt(A) € active T1 , 

=> create parcnt(A) -* create A (unless parent(A) = {U}). 

The Lemma follows by an obvious induction. I 

Lemma 6.3.1.2.7: Let v 6 V, T = T Q v, A € vertices. r , B € v-anc-scq T (A), then 
commit B -» create A 



V 



Proof: A € verticeSj. =» create A € v. 

B € v-anc-seq.^A) => 3A' € anc(A): (B,A') € seq. 

By Lemma 6.3.1.2.6, create A' -* * create A. 

v can be written as tpinp, with w = create A'. 
Let Tl = T qp, and let T2 = T qpw. 
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By precondition Pa.lc,-B € donc T1 , 



commit A -> create A' -+ * create A. I 



Lemma 6.3.1.2.8: Let v € X T = T v, A € vertices,, B € i-anc-seq,(A), then 

abort B -* create A 
Proof: Similar to the proof of Lemma 6.3. 1.2.7 above. I 

Lemma 6.3.1.2.9: Let v € 1^, T = T Q v, A € committed,-, B € v-prop-desc-,-(A), then 

commit B -+ commit A 

Proof: A € committed, => commit A € v. Note that since A has a proper descendant, A <£ 
accesses. Assume that B € v-child,(A); the Lemma follows from this case by an obvious 
induction. 

v can be written as tpir^- with w = commit A. 
LetTl = T <p, and let T2 = T <pw. 

But B cannot be created after A has committed, so B € vertices^. 

By precondition Pa.2b, B £ done T1 , 
=> commit B € 9, 
=» commit B -* commit A. I 

Lemma 6.3.1.2.10: Let v € 1^, T = T Q v, A € committedp B € i-child^A), then 

abort B -+ commit A 

Proof: Similar to the proof of Lemma 6.3.1.2.9 above. I 

Lemma 6.3.1.111: Let v € T^, T = T Q v, A,B € committedp B € v-precedeSy(A), then 
commit B -* commit A 
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Proof: Wc show C € v-precedes,(B) =» commit C -+ commit B. The Lemma follows by 
an obvious induction. 

C € v-preccdes r (B) => 

C € v-anc-scq.,.(B) V C € v-child^B) V C € v-data-anc^B). 

If C € v-anc-seq-j(B), then 

commit C -^ create B by Lemma 6.3.1.2.7. 

But create B -* commit B by Lemma 6.3.1.2.2, 
=» commit C -+ commit B. 

If C € v-child T (B). then 

commit C -* commit B by Lemma 6.3.1.2.9. 

If C € v-data-anc T (B), then 

C = BJ.c, where c € v-data^B), 

=> commit C -* commit B by Lemma 6.3.1.2.5. I 

taiiuna 6.3.1.2.12: Let v € t^, T = T Q v, A,B € committedp B € vset^(A), then 

commit B -* • commit A 
Proof: Immediate corollary of Lemma 6.3.1.2.11. I 

lamina 6.3.1.2.13: Let v € T t , T = T v, A € committedp. B € i-precedeSyCA), then 

create B -* commit A 

Proof: B € i-prccedcs^A) => 

B £ i-anc-seq T (A) V B € i-child^A) V B € i-data-anc^A). 

If B € i-anc-scq^A), then abort B -^ create A by I^mma 6.3.1.2.8, and 
create B -+ abort B, create A -+ commit A, 
=» create B -+ commit A. 
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If B € i-childpCA), then abort B -^ commit A by Lemma 6.3.1.2.10, and create B -+ 
abort B, 

=» create B -+ commit A. 

If B € i-data-anc^A), then B = crucial T (B') for some (B',A) € data T . Thus B € desc(B'). 

But by Lemma 6.3.1.2.4, commit B' -^ commit A, and by Lemma 6.3.1.2.6, create B -+ 
create B' -^ commit B' 

=> create B -* commit A. I 



Lemma 6.3.1.2.14: Let v € t" a , T = T Q v, A,B € committedp B € vsetjXA), C € 
i-prcccdeSy(B), then 

create B -+ commit A 

Proof: Immediate corollary of Lemmas 6.3.1.2.12 and 6.3.1.2.13. ■ 



6.3.2 Version-Compatibility in La 

Lemma 6.2.4.6 states that if T is a reachable AAT in LI, and A € vertices r , then vtree^A) is 
version-compatible. In this section we develop two lemmas which will be used in the proof of Lemma 
6.2.4.6. First we show that if T is any AAT which is version-compatible, then any restriction of T to a 
v-dataj-closed set is also version-compatible. We then show that any reachable tree in La is 
version-compatible. We will show in a later section that for any reachable tree, T, in LI, vtrcc-j^A) is a 
(backed up) restriction of T to a v-data r -closed set, which will complete the proof of Lemma 6.2.4.6. 

Lemma 6.3.2.1: Let T be an AAT, V C vertice&p where V is anc-closed and v-datay-closed. 
If T is version-compatible, then T|V is version-compatible. 

Proof: Let S = T|V. Note that S is an AAT since V is anc-closed. I^t A € datasteps^x). 

We must show that label s (A) = result(x,r), where r = «v-data s (A); data s ». 

By definition, label s (A) = label^A). 
But T is version-compatible, 
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=> labcl T (A) = result(x,r'), where 
r' = «v-data r (A); data T ». 

Thus it suffices to show r = r'. But data s C data..; thus it suffices to show set equality. It is 
obvious that r C r'. 

So suppose B € r\ B * A, 

=> B € visible T (A) A (B,A) € datap 

=> B € V, since V is v-data r -closed and A € V, 

=> B € visible s (A) A (B,A) G data g (since V is anc-closed), 

=> B€r. I 

Lemma 6.3.2.2: Let T € ?fc> a . Then T is version-compatible. 

Proof: Let A G datastcpSj(x). We must show that u (= label T (A)) = result(x,s), where s = 
«v-data f (A); data r ». 

Let T = T v, where v € "T can be written as <pinl>, with -n = perform A,u. 

LetTl = T Q qp, and let T2 = T <pw. 

By precondition Pa.4c, u = results'), where s' - «visible T1 (A,x); data T1 ». 

Tlius it suffices to show s = s\ and since data^ C data p it suffices to show set equality. 

First, let B € s. 

(B,A) € data r , but A € datasteps T2 => (B,A) € data^, 

=» B € datastepSpj, 

=> B € datasteps T1 (x). 

By precondition Pa.4b, B € datasteps.j ^(x) => B € visiblc n (A,x) V B € dcad fl (A,x). 

But if B € deadj.^A.x), then B € dcad^A.x) by Lemma 6.3.1.1.1c, 
=» B <£ visiblc-jM), which is a contradiction. 

Thus B € visible T1 (A,x), => B € s\ 

Conversely, suppose B € s\ We know B * A since A C datastcp&j-j. 
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(B,A) € data- n =» (B,A) € datap 

B C visible T1 (A,x) => B € visiblc T (A,x), =» B € s. I 

6.3.3 Properties of Aborts Sets in La 

In tliis section we present some properties of aborts sets for reachable trees in La. The first 
lemma is not strictly a property of aborts sets, but it justifies use of the recursive form of ABORTS in 
inductive proofs, so we include it here. 

Ivcmma 6.3.3.1: Let T € 9b , A € verticesp Then A £ v-prccedes T (A). 

Proof: LetT = T Q v for some v € T. Suppose A € v-preccdeSy(A). 
By Lemma 6.3.1.2.11, A € committcdp and 
commit A -»• commit A. 

V 

But -+ is acyclic for v € T so this is impossible. I 

Lemma 6.3.3.2: Let T € 9b a , A € committcdp (A,B) € seq, A * B, then 
ABORTS,(A) n dcsc(B) = 

Proof: Let T = T Q \, for some v € "T. 

ABORTS T (A) = Ui-prccedes-rCC) . 
1 C € vsetp(A) ' 

Let D € i-precedeSpfQ, for some C € vset^A). We show D i desc(B). Since A € 
committcdp create D -* commit A, by Lemma 6.3.1.2.14. 

But if D € desc(B), then commit A -* create D, by Lemma 6.3.1.2.7. But -+ must be 
acyclic, so we have a contradiction. I 



lamina 6.3.3.3: Let (T,T1) € 9b a \ and let A € committcdp Then 



ABORTS n (A) < ABORTS^A) 
Proof: ABORTS T1 (A) = Ui-prcccdcs n (B) 

1J BCvsctj-jtA) li 
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By Lemma 6.3.1. 1.3e, vsel n (A) = vsetj(A) 
=» ABORTS T1 (A) = Ui-precedes^B) 

11 BCvset^A) li 

But A € committedp and v-prccedes j(A) C committcdj. by Lemma 2.3.2, 
=» vset,.( A) C committed, by definition of vsetj.. 



But B € committedj- =» i-preccdes n (B) < i-precedes,(B), by Lemma 6.3.1.1.3f, 

=» ABORTS T1 (A) < Ui-precedes r (B) 
11 B € vsetf(A) ' 

=» ABORrS n (A)< ABORTS T (A). I 



ABORTS T1 (A) < Ui-precedes r (B) (using Lemma 2.2.1.1), 
11 B € vsetf(A) ' 



Lemma 6.3.3.4: Let (T.T1) € &< 2) , and let A € vertices,. Then 

SEQ-ABORTS n (A) < SEQ- ABORTS-^ A) 

Proof: SEQ-ABORTS T1 (A) = i-anc-scq T1 (A)U UABORTS T1 (B) 
1 l il B € v-anc-scq T1 fA) 

= i-anc-scq,(A) U UABORTS T ,(B) , by Lemma 6.3.1.1.1h. 
B € v-anc-seq-j-(Aj 

But B € v-anc-seq.j(A) => B € committedp 

=> ABOR'rS T1 (B) < ABORTS T (B), by Lemma 6.3.3.3. 

The lemma follows directly using Lemma 2.2.1.1. I 



6.4 Proof of Possibilities Map for h 10 

We now return to the task of showing that h 10 is a possibilities map. First we must prove 
Lemmas 6.2.4.5, 6.2.4.6, and 6.2.4.7. 

We first state an obvious lemma for LI: all reachable AATs arc in ANC- ABORT. 

Lemma 6.4.1: Let T € ft r Then T € ANC-ABORT. 

Proof: Let T = T Q v, for some v € T" r If v * A, then T = Te for some e € 6,, T € PRE,(e), 
and by the ANC-ABORT precondition for e, T € ANC-ABORT. If v = A, then T = T Q 
which is trivially in ANC-ABORT. I 
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Wc will use this ANC-ABORT property, together with results from La, to prove Lemmas 
6.2.4.5, 6.2.4.6, and 6.2.4.7. 

Let la denote the property of T which is the conjunction of the properties stated in Lemmas 6.3.1.1.2, 
6.3.1.1.4, 6.3.2.2, 6.3.3.1, and 6.3.3.2. (Recall that all invariant abbreviations are cross-referenced to 
lemmas in Appendix I.) 

Let Ja denote the pair-property of T which is the conjunction of the pair-properties stated in Lemmas 
6.3.1.1.1, 6.3.1.1.3, 6.3.3.3, and 6.3.3.4. 

Lemma 6.4.2: la is invariant in LI, and Ja is pair-invariant in LI. 

Proof: h ]a is a possibilities map by Theorem 6.3.1. But h la fixes T. Since la is invariant for T 
in La, la is invariant for T in LI by Lemma 4.2.4.3.5. Similarly since Ja is pair-invariant for 
T in La, Ja is pair-invariant for T in LI, by Lemma 4.2.4.3.5. I 

Let Sa denote the property of event sequences which is the conjunction of the properties stated in 
Lemmas 6.3.1.2.1 through 6.3.1.2.14. 

Lemma 6.4.3: Let v € f r Then Sa holds for v. 

Proof: Since h. is a possibilities map, it is a valid interpretation, by Lemma 4.2.2.5. Thus 
h, (v) € f. But h, is the identity map on events, so h,(v) = v. Since Sa holds for all event 

13 3 J 3 J 3 

sequences in t^, Sa holds for v. I 

Now we prove a preliminary lemma for LI, which shows that tracing back the visible precedence relation 
from any action cannot lead to an ancestor of that action. 

Lemma 6.4.4: Let T € % v and let A € verticesy. Then anc(A) H v-precedcSy(A) = 0. 

Proof: Suppose B € anc(A) fl v-precedcs-j(A). 

By Lemma 2.3.2, B € v-prccedcSy(A) =» B € committcd r By l^cmma 6.3.1.1.2f, A € 
desc(B) => A € visible^ B), or A € dead,.(B). 

If A € visible...(B), then by I^cmma 6.3.1.2.9, 
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commit A -* * commit B. 

But B € v-prccedcSy(A), A € committedj- =» commit B -+ commit A, by Lemma 
6.3.1.2.11, a contradiction. 

If A € dead r (B), then let C be the lowest (in ancestor order) action in anc(A) D v-desc^B). 
Clearly C € vset,(B) => C £ vsct r (A), by Lemma 2.3.3a. A € prop-desc(C) since A i 
visible T (B). Let D = QA. 

But D C committedj., since otherwise D would be visible to B, contradicting our choice of C 
as the lowest visible descendant of B which is an ancestor of A. 

=» D€ aborted] (by Lemma 6.3.1.1.2c), 

=> D € i-child,(C) =* D € ABORTS T (C). 

But C € vsei r (A) =» ABORTS T (C) C ABORTS T (A), by Lemma 6.2.1.5, 
=* D € ABORTS^A). 

But D € anc(A), which contradicts T € ANC-ABORT. I 

6.4. 1 Proof of Lemma 6.14.5 

Let T € 9b r A € verticesj. Let S = vtree^A). By Lemma 6.4.4, anc(A) D v-prccedeSy(A) = 0, 
=» prop-anc(A) D vset^A) = (since vset r (A) = v-precedeSy(A) U {A}), 
=> S is a view tree for A in T, by Lemma 3.5.2. I 

6.4.2 Proof of Lemma 6.2.4.6 

Let T € % r A € vcrtice&y. Let S = vtree^A). By Lemma 6.3.2.2, T is version-compatible. 

Let W = vsetjXA) U prop-anc(A). By Lemmas 6.4.4 and 3.5.2, vtree^A) = (T|W)//A. W is 
v-datap-closed by lxmma 2.3.3c. By Lemma 6.3.2.1, T|W is version-compatible. But since backing up 
proper ancestors of A to active status cannot affect the labels of accesses of S, S is version-compatible. 
I 
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6.4.3 Proof of Lemma 6.2.4.7 

Let T € % v A € verticeSp 

We show that if S = vtrec T (A), then seq s U sibling-data s is acyclic. Let V = vsel^A), W = vset r (A) U 
prop-anc(A). By Lemmas 6.4.4 and 3.5.2, S = (T|W)//A. Thus data g C data p scq s C seq r The proof 
will be by contradiction: 

Let (Ap A 2 ,..., A n ) be a cycle in scq s U sibling-data s (with n > 2). 

then (A,, A, A ) is a cycle in seq r U sibling-data r , and A. € W. 

Let P be the common parent of {A}. 

We will use the convention that subscripts are taken modulo n, i.e. we regard A n+1 = Ay 
First we prove a preliminary lemma: 

tamma 6.4.3.1: If A C dcsc(Aj) U desc(A i+1 ), then A ; € v-precedeSj(A J+1 ). 

Proof: We show A i € vset^A^j). Since A ; * A i+1 , the Lemma follows directly. 

(A^A^^eseqs 

=» (Aj, A i+ : ) G seq T , and A ; , A j+ j € visible^ A) (since vertices s C visible^ A).) 
But A € descfAj) U desc(A i+1 ) =► A 4 , A j+1 € visible^P), 

=» AjGv-seq^A^j), 

=» A^vset^A^j). 

(A ; , A j+1 ) € sibling-datag 

=» 3^ € desc(Aj), a i+1 € desc(A i+1 ): (a^ a i+1 ) € data r , and a^ a j+1 € visible^A) (since 
vertices s C visible-pCA).) 
But A € dcscfAj) U dcsc(A i+] ) =» z { , a j+1 € visible^P), 

=» aj € visiblej^a^j), =» a ; € v-data^a^j), 

=» A ; € v-data-anc^a^j). =» A i € vsetpta^j). 

But a j+1 € visible^P) 

=> a i+1 €v-desc T (A. + 1 ),« a j+1 € vset^A^), 
=» A^vset^A^j). I 
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Proof of Lemma 6.2.4.7 (continued): 

Suppose that A i dcsc(A s ) Vi; then by Lemma 6.4.3.1, A } € v-precedes|(A i + 1 ) Vi, 

=» A. G v-prccedcs^Aj) (since the A. form a cycle), which contradicts Lemma 6.3.3.1. 

Thus A G desc(A), for some i. Assume without loss of generality that A € desc(A n ). 

Since n > 2, Aj * A R . But A 1 € verticeSg, and A y € anc(A), 
=> A, G vprecedcSj(A). 

Aj G vprcccdcs^(A) 

=> ABORTS T ( Aj) C ABORTS T (A), by Lemma 6.2.1.5. 

Since (A,A T ) € scq s U sibling-data s , we have two following cases: 

1. (A^Aj) € seq s 

2. (A n ,Aj) € sibling-datag 

Casel: (A^A^Gseq =» A n € done p by Lemma 6.3.1.1.2b. 

If A n G abortedp then A n G i-anc-seq T (Aj), =» A n G ABORTS.^), 
=» A G ABOR TS^A), which contradicts T G ANC-ABORT. 

If A n G committed T , then A n G v-anc-seq-^A^, =» A n G v-preccdes 1 (A 1 ), 
=» A Gv-prcccdcs*( A), which contradicts Lemma 6.4.4. 

Case 2: (A^Aj) G sibling-dat^ 

=* 3b n G dcsc(A n ), bj G desc(A 1 ): (b n , b x ) G data,-. 

b x G visible^A) =» b x G visible ,(P), => b, G v-dcsc T (Aj), =» bj G vsel^Aj), 
=» b, G v-precedcSy(A), 
=> ABORTS^) C ABORTS^A). 

Case 2a: b n G visible T (b 1 ), 

=» b n G v-data 1 <b 1 ), =» A n G v-data-anc^bj), => A n G v-prccede&^bj), 
=» A Gv-prcccdcs*( A), contradicting Lemma 6.4.4. 
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Case 2b: b n i visible^) • 

-» b n € i-data^bj) (See Fig. 6.1.) 

Let B = crucial.j<b n ). By Lemma 6.3.1.1.2g, B is defined, and B € desc(A n ). 
B € i-data-anc^) =» B € ABORTS^). =» B € ABORTS^A). 

But B € anc(A), since b n € visible.,(A), contradicting T € ANC-ABORT. I 

6.4.4 Proof that h 10 is a Possibilities Map 

We now have all the facts needed to show that h 10 is a possibilities map: 

Theorem 6.4.4.1 : h 10 is a possibilities map. 

Proof: h 10 preserves initial states by Lemma 6.2.4.1. h 10 preserves transitions by Lemma 
6.2.4.2. We have proven lemmas 6.2.4.5, 6.2.4.6, and 6.2.4.7; thus every reachable state in LI 
is view-serializable (Theorem 6.2.4.4). Thus h 10 preserves preconditions by Lemma 6.2.4.3. 
By Lemma 4.2.2.6, h 10 is a possibilities map. I 



Fig. 6.1. Case 2b, Lemma 6.2.4.7 



Vi 




b lt c 
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6.5 Level 2 Algebra and Mapping h 2] 

At Level 2 we replace the ANC- ABORT condition with a precondition on perform events. 
Otherwise everything in Level 2 is identical to Level 1. 

L2 = (8 2 , 2 2 , a 2 , t 2 ) 

g = g = {create A, commit A, abort A, perform A,u}. 

2 2 = 2p the set of all augmented action trees. 

a 2 = 0l = T . 

t 2 , the transition relation, is obtained by deleting the ANC-ABORT preconditions Pl.ld, P1.2c, P1.3b, 
and P1.4d, and by inserting a new precondition for perform events: 

(P2.4d) B € visible^A.x) -» anc(A) n ABORTS^AjB) = 

We define the trivial mapping h« : L2 -* La as the identity map on states and events. 

Theorem 6.5. 1 : h^ is a possibilities map. 

Proof: Because the ANC-ABORT conditions do not appear in algebra La, every precondition 
at Level A also appears at Level 2 (in addition, Level 2 has precondition P2.4d). Thus h^ 
preserves preconditions. All transitions are identical in La and L2; thus h^ preserves 
transitions. Initial states are identical in L2 and La; thus h^ preserves initial states. By 
Lemma 4.22.6, h- is a possibilities map. I 

Since h^ fixes T, all invariants (and pair-invariants) for La are invariant (or pair-invariant) for 
L2: 

Lemma 63.2: la is invariant in L2, and Ja is pair-invariant in L2. 

Proof: Since h. is a possibilities map which fixes T, and la is invariant for T in La, la is 
invariant for T in L2 by Lemma 42.4.3.5. Similarly since Ja is pair-invariant for T in La, Ja 
is pair-invariant for T in L2, by Lemma 42.4.3 5. I 
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6.5.1 Specification of Mapping h 21 

We define the trivial mapping h 21 : L2 -*• LI as the identity map on states and events. We must 
show that this mapping is a possibilities map. 

Lemma 6.5.1.1: h 21 preserves initial states. 

Proof: Trivial, since a 2 = ff r I 

Lemma 6.5.1.2: h 21 preserves transitions. 

Proof: Trivial, since all transitions are identical in L2 and LI. I 

We must also show that h 21 preserves preconditions. We use the following lemma to reduce this 
problem to the ANC-ABORT condition on reachable states in L2: 

Lemma 6.5.1.3: Suppose that for all T € 3> 2 , T € ANC-ABORT. Then h 21 preserves 
preconditions. 

Proof: It is obvious that h 21 preserves all preconditions except for the ANC-ABORT 
conditions, since all other preconditions appear at Level 2. We must verify that the 
ANC-ABORT conditions hold; these conditions state that the next state is in ANC-ABORT, 
Le. 

T € PRE 2 (e) n *Jb 2 , h 21 (T) € & x =* h 21 (T)h 21 (e) € ANC-ABORT 

But h^CDh^e) is just Te, since h n is the identity mapping. Thus we will must show 

T € PREjCe) n ft 2 , h n (T) € % 1 -» Te € ANC-ABORT. 

But T € PREj(e) n * 2 ■» Te € & 2 . Thus it suffices to show mat all reachable states in L2 
are in ANC-ABORT. I 

Our main result for L2 is thus that all reachable states are in ANC-ABORT, which will imply 
that hjj preserves preconditions (and is thus a possibilities map): 
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Lemma 6.5.1.4: Let T € % v Then T € ANC-ABORT. 

Proof: Take A € verticeSp We show anc(A) n ABORTS^A) = 0. 

The proof uses induction based on the recursive form of ABORTS: 

ABORTWA) = i-precedesUA) U U ABORTSUB) 
1 ' Bt v-precedes^A) 

Recall that by Lemma 6.5.2, we can use any results from la or Ja since we have shown that 
these properties are invariant n L2. 

Thus Lemma 6.3.3.1 (in la) justifies the use of the inductive proof method. 

Assume the Lemma holds for all B € v-precedcs^A): anc(B) C\ ABORTS^B) = 0. 
First we show i-precedesJA) fl anc(A) = 0: 

B € i-anc-scq^A) =» (B,A') € seq, for some A' € anc(A), B * A', 
=» B€anc(A). 

B € i-child^A) =» B € children(A), 
=» B*anc(A). 

B € i-data-anc^A) => 3B' € i-data^A): B = crucial^B'). 
But by Lemma 6.3.1.1.2& crucial^B') € desc(AiB) 
=> BCanc(A). 

Now we show B € v-precedes^A) => anc(A) n ABORTS^B) = 0: 



a. B € v-anc-seq^A) =» (B,A') € seq, for some A* C anc(A), B * A', 
=» ABORTS^B) D destfA') = 0, by Lemma 6.3 32. 

But by Induction Hypothesis, ABORTS^B) fl anc(B) = 0. 
But anc(B) = {B} U proper-anc(A'), since (B,A*) € siblings, 

=» anc(A) Q descCA") U anc(B), 

-» ABORTS^B) D anc(A) = 0. 

b. B € v-childjIA) =» ABORTS^B) fl anc(B) = 0, by Induction Hypothesis. 
But B € children(A) => anc(A) C anc(B), 

w ABORTS^B) n anc(A) = 0. 
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c. B € v-data-anc^A) =» 3B' € v-data,{A): B = AJB', 
=» ACdatastepSp 

Let T = T Q v, where v € 1j can be written as f w^, with tr = perform A,u. 
LetTl = T Q <p, and letT2 = T q>». 

Let A,B' € datasteps(x). 

By Lemma 6.3.1.1.1c, (B\A) € data^, 

=» B' € datastepsj-^x). 

By precondition P2.4b, B' € visible^A.x) V B' € deadj.^A.x). 

B' € v-data^A) =» B' € visible T1 (A,x), 

=» anc(A) n ABORTSj-^AiB') = 0, by precondition P2.4d (the orphan 
detection precondition), 

=» anc(A) PI ABORTS. ri (B) = 0. 

But ABORTS^B) < ABORTS^B), by Lemma 6.3.3.3 (since B € 
committed^), 

=» ABORTS^B) n anc(A) = 0, by Lemma 2.2.1.1d. I 



6.5.2 Proof that h 21 is a Possibilities Map 

We now have all the facts needed to show that h 21 is a possibilities map: 

Theorem 6.5.2. 1 : h^ is a possibilities map. 

Proof: h n preserves initial states by Lemma 6.5.1.1. h 21 preserves transitions by Lemma 
6.5.12. Since we have shown that all reachable states in L2 are in ANC-ABORT (Lemma 
6.5.1.4), h 21 preserves preconditions by Lemma 6.5.1.3. By Lemma 4.2.2.6, h^ is a 
possibilities map. I 
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7. Partially Localized Model 

In a distributed event-state algebra all preconditions for events are localized to the nodes at 
which those events occur (or to the message buffer). The Level 2 model is defined in terms of a single 
global stale, the global AAT. As we move towards a distributed model, we partition the state into distinct 
components, and we attempt to localize preconditions to these components. At Level 3, we define an 
abstract set of locations, and we give each location a (local) state. This local state will consist of a UAS at 
each location, and an ordering on datasteps at each object (The data ordering in an AAT is already 
"localized," since dataj individually orders datasteps at each object) 

These locations are simply containers for information; they need not correspond directly to 
physical locations (nodes) at the lower levels. In a later chapter we will construct a mapping from a 
distributed model where state is partitioned among nodes, to this localized model where state is partitioned 
among locations. Essentially several abstract locations can reside at a single physical node. One 
advantage of using abstract locations at this higher level is that we need not be concerned with how 
information is physically distributed. 

We can think of locations as "abstract nodes." We will consider each action and object to be a 
separate location; the information at these locations will represent the view at that action or object It will 
be convenient to allow other (unspecified) locations as well. The events at this level will be either local 
steps," which are conceptually local to a particular location, or "communications steps," which transfer 
information from one location to another. Transfer of information is instantaneous (i.e. there is no analog 
to the message buffer at this level). (We will show later that we can model communications delays by 
regarding "message slots" in the message buffer as locations. Thus we do not specify the complete set of 
"locations" at this level; locations can be viewed abstractly as any information holders.) 

We show that it is straightforward to localize all preconditions except for the orphan detection 
condition (precondition P2.4d: B € visible^x) =» anc(A) fl ABORTS,<AiB) = 0). 

7.1 Level 3 Algebra 
L3 = (8 3 , 2 3 , o y Tj) 
State Space: 
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Letfloc. (the "tree locations"-) = (act - {U} - accesses) U obj. 

Let loc. be a set of "locations," where tloc C loc. 

(We exclude U from doc because it is a virtual action; thus we associate no information with it directly. 
Also, we exclude accesses from tloc because we regard them as being coupled to their objects for 
information.) 

2 3 = {<T,L>}, where the components are 

T - the "global state", an augmented action tree (as in L2) 
L - the "local state", where L: loc -♦ UAS 

Notation 

If "prop" is some property (function, relation, etc.) defined on UAS, then we denote prop^ by 

"@propjo]" (for example, visible L(a) (A,x) = @visible L {aKA,x)). 
The "@" symbol flags components of the local state (as opposed to components of the global AAT). We 
also use the "@" symbol to distinguish communications events from "local" events, since the 
communications events only affect the local state. 

We further abbreviate by writing @propjA] for ©propjx] when A € accesses^) 

Initial State: 

a 3 = <T ,L > 

T Q - the trivial AAT, as in L2, 

L^a) = T u - the trivial UAS, Va € loc. 

Essntsi 

Events create, commit, abort, and perform are localized to individual locations (except for the orphan 
detection precondition). We regard an action as being created at the location of its creator, and 
committed or aborted at its own location (or the location of its object if it is an access). (Recall that for A 
* U, creator(A) = parent(A) unless A € top, and creator(A) = A for A € top.) 



Ill 



,„ .«*. to the ".oca." events (create, commit, abort, perform), »e muoduce "communications events 

* move information from one tocation to another. Tire "source" of information is arbitrary ■ * each 

««r communications events are parameter^ by a singto tocaion: the donation ofthc informal 

Hansfer. A. tower tove.s we wil. parameters communications events by me sender of taformanon . 

well. 

The communications events are as follows: 

@create[a]A -- create action A at location a 

©committal A " commit action A allocation a 

@aborU>] A " abortaction A allocation « 

me transition relation is defined so that each communications event is idempoten, i.e., the effect of a 
communications event which occu. multiple times is me same as the effect of this event occumng a 
single time. Idempotency "filters out" duplicate communications events. 

Transition Relation! 

Lete € 63, <T,L> € 2 3 , <T,L>e = CT1,L1>. 

1. cjejteA (A€act-{U» 

PRECONDITIONS: 

a. A € ©verticesJcreatorCA)] 

b. parenKA) € ©activeJcreaMA)] 

c. (B,A) €seq,B*A=»B€ ©doneJcreatorCA)] 
TRANSITIONS: 

a. vertice& n ♦- verticeSy U {A} 

b. status^A) «- 'active' 

c. ©verticesJcreatortA)! - @vertices L [creator(A)] U {A} 
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d. @status L1 |crcator(A)KA) «- 'active' 

2. commit A (A € act - {U} - accesses) 
PRECONDITIONS: 

a. A € ©activejA] 

b. @childrenjAKA)C@done L [A] 
TRANSITIONS: 

a. statu&j-^A) *— 'committed' 

b. @status u [AKA) +- 'committed' 

3. abort A (A€act-{U» 
PRECONDITIONS: 

a. A € @activeJA] 
TRANSITIONS: 

a. statu^A) <- 'aborted' 

b. @status L1 [AKA) ♦- 'aborted' 

4. perfonn A.u (A € accesses(x), u € values(x)) 
PRECONDITIONS: 

a. A € ©activejx] 

b. B € ©datastcpsJxKx) => B € @visibleJxKA,x) V B € @dead L [xJ(A,x) 

c. u = result(x,s), where s = «@visible L {xXA,x); 0(x)», and = ordertT). 

d. B € @visible L txKA,x) -» anc(A) fl ABORTS^AJB) = 
TRANSITIONS: 

a. statuSy^A) ♦- 'committed' 
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b. @status L1 [xKA) ♦- 'committed' 

c. label T1 (A) ♦- u 

d. dataj-j «- dat^ U {(B,A): B € datasteps^x)} U {(A,A)} 

5. g£i£aieIfl]A (A€act-{U},a€loc) 
PRECONDITIONS: 

a. A € @vertices L [/8], for some /? € loc 
TRANSITIONS: 

a. @vertices u [a] <- ©verticesja] U {A} 

b. A $ ©verticesja] =» @status L1 {aJ(A) ♦- 'active' 

6. (gJcommitfal A (A € act - {U}, o € loc) 
PRECONDITIONS: 

a. A € @committcd L |/J], for some p € loc 
TRANSITIONS: 

a. @vertices u [a] ♦- ©verticesja] U {A} 

b. @smus L1 [a}iA) *- 'committed* 

7. (SJabortfttl A (A € act - {U}, a € loc) 
PRECONDITIONS: 

a. A € ©abortedj/?], for some ft € loc 
TRANSITIONS: 

a. ©verticesLjla] «- ©verticesjal U {A} 

b. ©status^KA)*- 'aborted' 
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7.2 Specification of Mapping h 32 

We define a (single-state) mapping from L3 to L2, h 32 : L3 -»• L2. (We abbreviate "h 32 " as "h" 
in this chapter.) 

State Mapping 

h: 2 3 -♦ 2 2 is defined by h(<T,L>) = T, V<T,L> € 2 3 . Thus h fixes T. 

Event Map pin g 

h: 8 3 -» 6 2 is defined by 

h: create A -* create A 

commit A -* commit A 

abort A -» abort A 

perform A,u -+ perform A,u 

@create[a]A -* A 
@commit[a] A -* A 
@aboru>]A -* A 

7.3 Level 3 Invariants 

The following simple pair-invariants are analogous to the Level A pair-invariants from Lemma 6.3.1.1.1: 

Lemma 7.3.1: Let (<T,L>,<T1,L1>) € ^\ Then the following pair-invariants hold (Let a 
€ loc, x € obj, A,B € act): 

a. ©verticesja] C ©verticesylal ©committedja] Q @committed L1 [a], 
©abortedjaj £ @aborted u [al ©donejoj Q @done L1 [a] 

b. B is dead in Mot) =* B is dead in Ll(o); B is live in Ll(o) =» B is live in L(o) 

c. @visible L [oKA) Q @visible u (oKA), ©deadJoKA) Q @dead L [«XA) 

Proof: Straightforward. I 
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The following invariants relate local states to the global state. Essentially each local state 
represents a "partial view" of the true global state. We show these invariants relative to mapping h: Since 
h fixes T, all invariants and pair-invariants for T in L2 can be applied to the proofs (by Lemma 4.2.4.3.6). 
Recall that we have shown in Lemma 6.5.2 that invariants la and Ja from Level A are invariant in L2. 

Lemma 7.3.2: Let <T,L> € 3> 3 . Then the following are invariant relative to h. (Let o € loc, 
x € obj, A,B € act): 

a. A € verticesj. - {U} «=» A € @verticesJcreator(A)]; 
U € activej A U € ©activejo] (Vo € tloc) 

b. A € committedp «=» A € @committedJA] 

c. A € abortedj. «=> A € ©abortedJA] 

d. A € donej «=► A € @donejA] 

e. A € datastcpSj(x) «=> A € ©datastepsJxKx) 

f. ©vertices^a] C vertice&p ©committedja] C committed^ @aborted L [a] C 
abortedy, (Sdoncja] C donej 

(Note: @active L [o] C activej does not necessarily hold.) 

g. A C @activejA] =» A € activej 
(Note: not necessarily conversely) 

h. B € ©visibleJaXA) => B € visible^A) 

i. B € @deadJoKA) => B € deadj(A) 

j. (B,A) € dataj (A,B € accesses(x)) =» 
B € visiblCj(A) « B € @visible L [x](A) 

k. (B,A) € dataj (A,B € accesses(x)) »» 
B € deadj(A) » B € @deadJxKA) 

1. (B,A) € dataj. (A,B € accesses(x)) =* 

B € ©deadJxKA) »» {crucialj(B)} <, @abortcd L [xJ 



Proof: 



116 



a. If A * U, A €• verticcs-p then there must have been an event create A, which 
also has the effect of placing A in @verticcsJcrcator(A)]. Using Lemma 7.3.1a, 
we conclude that A € vertice&j- =» A € ©verticesJcreatontA)]. 

Conversely, if A € ©verticesJcreatoitA)] then mere must have been an event 
create A, or ©crcatc[crcator(A)] A. Consider the first such event If it is create 
A then A € vertkeSy. Now suppose there were an event @crcatc[a] A, for some 
a, that preceded create A. Let e be the first such event, and let the state 
immediately before the execution of e be <T1,L1>. By the precondition for e, A 
€ ©vertices, j[0] for some p. But if A € ©vertices^], then either fi = 
creator(A) and create A precedes e, or an event f = @creatcf/3] A precedes e. 
Both cases contradict our choice of e. 

U € activ&j. by Lemma 6.3.1. 1.2d. To see that U € ©activeja], note that U € 
©active, [ol but no event can change U's status. 

b. Similar to (a). 

c. Similar to (a). 

d. Follows directly from (b) and (c). 

e. A C datasteps^x) «=» A € committed^ 
<=» A € ©committedjjx] by (bX 

«=» A € ©datastepsJxKx). 

f. We argue ©verticesja] C vertices^ the other cases are similar: If a = 
creatotfA), then the result follows dirccdy from (a). Otherwise we can show 
©vertkesjoj Q verticeSy by induction on the number of events in a valid 
sequence generating <T,L>. In the initial state ©verticeSjJal = vertkeSj. = {U}. 
But verticesjo] can only increase when an event ©createfa] A occurs, which 
requires as precondition A € ©vertices^] for some fi (where <T1,L1> is the 
state before this event occurs). By induction hypothesis, A € ©verticesLjI/fl -» 
A € vertices^ =-» A € verticeSy. 

g. A € ©activeJA] =» A € verticeSj. from (f). If A € done^ then A € 
©donejA] by (d) -- a contradiction. Thus A € activfrp 

h. B € ©visibleJaKA) -» anc(A) n prop-desc(lca(A,B)) Q ©eommittedja]. 
But ©eommittedja] Q committed r by (f), 
=» B € visible^A). 

i. B € ©dcadJoKA) -» anc(A) n prop-desc(lca(A,B)) fl ©abortedjal * 0. 
But ©abortedjo] C aborted,, by (0, 
=» B€dead^A). 
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j. B € @visible L [xKA) => B€ visible j( A) by (h). 
B € visible^A) =» B € visible^A.x), 
=» B € @datastepsjx](x). Assume B * A (otherwise the result is obvious). 

Let<T,L> = a 3 v,v€r 3 . 

Let v = q>m$, where w = perform A,u, andlet<Tl,Ll> = ojp. 

(B,A) € dataj. -» (B,A) € data^, by Lemma 6.3.1.1.1c, -> B € datastep&jj, 

=> B € ©datastepsLjlxKx), by (e), 

=• B€@visiblc u lxKA.x) V B € @dead L1 [xKA,x) byP3.4b. 

But B € @dead L1 [xKA,x) -» B € dead^A.x) (by (i)), => B € dcad^x) -- a 
contradiction. Thus B € @visible u [x](A,x), 
=> B € @visible L [xKA,x) (using Lemma 7.3.1c). 

k. Similar to (j) above. 

1. B € @deadJxKA,x) =» anc(B) (1 ©abortedjx] * 0, 
=» @crucialJxKB) is defined. 
But anc(B) n ©abortedjx] Q anc(B) n abortedp by (0, 
=» crucial.^ B) € descfdicrucialJxXB)), 
=> {crucial^B)} < ©abortedjxj. 



7.4 Proof of Possibilities Map for h J2 

We now show that h is a possibilities map. Let 13 denote the conjunction of all properties in 
Lemma 7.3.2. We will show mat h is a possibilities map relative to 13. 

Lemma 7.4.1: h preserves initial states. 
Proof: Immediate since rKCT^LQ)) = T fl . I 

Lemma 7.4.2: h preserves transitions relative to 13. 

Proof: We must show that if <T,L> € PREj(e) n 9b 3 n 13, and h«T,L>) € PRE^Ke)) n 
* 2 ,then h(<T,L>e) = h(<T,L>)h(e). 

But h(<T,L>) = T, so we must show the following: 
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If<T,L> € PREj(e) H * 3 (1 13, and T € PRE/hfe)) D $ 2 , and <T,L>e = <T1,L1>, then Tl 
= (T)h(e). 

For the communications steps in L3 (e = ©create, ©commit, ©abort), T is not altered, and 
h(e) = A,soTl = T = (T)h(e). 

For the local steps (e = create, commit, abort, perform), it is easily verified by inspection that 
the effects of events on T are identical in L2 and L3. But h(e) = e, so Tl = (T)h(e) = (T)e. 
I 

Lemma 7.4.3: h preserves preconditions relative to 13. 

Proof: We must show that if <T,L> € PRE 3 (e) n 3b 3 PI 13, and h(<T,L>) € a» 2 , then 
h«T,L»€PRE 2 (h(c)). 

Since h(<T,L>) = T, we show 

<T,L> € PRE 3 (e) n & 3 n 13, T € % 2 -» T € PREjCKe)). 

For communications steps, e, h(e) = A, and preservation of preconditions follows vacuously. 
For local steps, h(e) = e. We prove preservation of preconditions for each local step in turn: 

1. create A 

a. P3.1a =* At @vertices L [creator(A)], 
=► A C vertices^ by Lemma 7.3.2a. 

b. If A € top, then parent(A) = U, U € active^, by Lemma 7.3.2a. 
Otherwise crcator(A) = parcnt(A), 

=» parenKA) € ©active L [parent(A)] by P3.1b, 
=» parent( A) € active^, by Lemma 7.3.2g. 

c. (B,A) € scq, B * A -• B € ©doneJcreatorfA)] by P3.1c, 
=» B € donej by Lemma 7.3.2g. 

2. commit A 
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a. P3.2a =» A € ©activeJA], 

=► A € activej. by Lemma 7.3.2g. 

b. Let B € children .,{ A). A * U => B I top, 
=» creator(B) = A, 

=» B € @:verticesjA] by Lemma 7.3.2a, 
=> B€@;children L [AKA), 
=* B € ©donejA] by P3.2b, 
=» B € done T by Lemma 7.3.2f. 



3. abort A 



a. P3.3a => A € ©activejA], 
=» A € activej by Lemma 7.3.2g. 



4. perform A,u 



a. P3.4a =» A € @active L [x], 
=» A € ©activeJA], 

=» A € activep by Lemma 7.3.2g. 

b. B € datasteps^x) =» B € ©datastepsJxXx) by Lemma 7.3.2e, 
=► B € <g;visible L [xKA,x) V B € @deadJx](A,x) by P3.4b. 

B € @visibleJxKA,x) =» B € visible J (A,x) by Lemma 7.3.2h. 
B € @dead L [xKA,x) ==» B € dead^x) by Lemma 7.3.2i. 

c. P3.4c =» u = rcsult(x,s), where s = «@visible L [x](A,x); 0(x)», 
and = order(T). We must show s = s\ where s' = 
«visible T (A,x); data T ». By definition, 0(x) and data f are identical 
on datasteps(x), so it suffices to show @visible L M(A,x) = 
visible T (A,x). 

@visible L [x}(A,x) C visible T (A,x) by I^emma 7.3.2h. So take B € 

visible^ A,x), 

=» B € ©datastepsJxKA.x) by Lemma 7.3.2e, 

=» B€@visible L [xKA,x) V B € @dead L M(A,x) byP3.4b. 

But B € @dead L [xJ(A,x) -» B € deadjCA.x) (by Lemma 7 3 2i) ~ a 
contradiction; 
=» B € @visible L [x](A,x). 
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ii. B € visible^A^) => B € @visible L [xXA,x) (as in (c) above), 
=► anc(A) n ABORTS^AiB) = by P3.4d. I 



Lemma 7.4.4: h is a possibilities map relative to 13. 

Proof: Follows immediately from Lemmas 7.4.1, 7.4.2, 7.4.3, and from Lemma 4.2.4.2.4. I 

Theorem 7.4.5: h is a possibilities map, and 13 is invariant in L3. 

Proof: By Lemma 7.3.2, 13 is invariant relative to h. By Lemma 7.4.4, h is a possibilities map 
relative to 13. We apply Lemma 4.2.4.2.6 to conclude that h is a possibilities map, and 13 is an 
invariant I 

Since h 32 is a possibilities map which fixes T, all invariants and pair-invariants from L2 carry 
down to L3. Let J3 denote the conjunction of all pair-properties from Lemma 7.3.1. We summarize the 
invariants for L3 as follows: 

Lemma 7.4.6: 13 is invariant in L3, la is invariant in L3, J3 is pair-invariant in L3, and Ja is 
pair-invariant in L3. 

Proof: Invariance of 13 is shown in Theorem 7.4.5. J3 is pair-invariant in L3 by Lemma 7.3.1. 
Since h 32 is a possibilities map which fixes T, and la is invariant for T in L2 (by Lemma 6.5.2), 
la is invariant for T in L3, by Lemma 42.4.3.5. Similarly since Ja is pair-invariant for T in L2 
(by Lemma 6.5.2), Ja is pair-invariant for T in L3, by Lemma 4.2.4.3.5. I 
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8. Value Maps -• A Model of Atomic Objects 

At Level 4 we introduce value maps as a data structure for keeping lock and version information 
about objects. A value map is a mapping from each object to a "stack of versions" for that object; each 
version is associated with an action (hat holds a lock on that object This data structure corresponds 
roughly to the implementation of atomic objects as described in [Moss81]. In Moss's locking scheme, a 
lock can be held on an atomic object at each level in the action tree. This scheme constrains all holders of 
a lock on a particular object to be related. We note again that we are dealing only with mutual exclusion 
locks. Moss develops a more general locking protocol which distinguishes between read locks and write 
locks. 

We regard these value maps as an abstraction of the information which is already present in the 
local UAS's at each object. In this sense the value maps introduce no new information into the state. As 
we stressed in Chapter 4, the state in an event-state algebra is simply one convenient way of capturing 
execution histories. Value maps are a convenient abstraction of execution histories because the 
preconditions on a perform event can be stated easily in terms of value maps. 

Level 4 is no more "localized" than Level 3. The events in Level 4 are identical to those in Level 
3 (though transitions and preconditions are reformulated in terms of value maps), and the event mapping 
h 4J is the identity. In particular, then, the communications events at Level 4 are still very simple, and 
they do not include enough information to allow localization of the orphan detection precondition. The 
non-local orphan detection precondition appears unchanged at Level 4. 

8.1 Level 4 Algebra 

L4 = <8 4 ,2 4 ,a 4 ,T 4 ) 

State Space: 

2 4 = {<T,L,V>}, where the components are: 

T - the global state, an augmented action tree (as in L2), 
L - the local state (mapping loc to UAS) (as in L3), 
V - a value map. 
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A value map gives a set of values for each object -- one value for each action which "holds a lock" (and 
thus a version) on that object 

V: obj X act -► values U {_!_} 

(where VA € act, x € obj. V(x,A) € values(x) U {_L}). 

Define V(x) = {A € act: V(x,A) * _!_}• (V(x) represents the actions which hold locks on object x.) 

If V(x) forms an ancestor chain, then define 

V(x).holder = the lowest (in anc-order) element of (V(x)), Le., 

V(x).holder € V(x), and VB € V(x), V(x).holder € desc(B). 

(If V(x) does not form an ancestor chain, then V(x).holder is undefined. For reachable states in L4, V(x) 
will always form an ancestor chain (see below).) 

If V(x).holder is defined, then define V(x). value = V(x,V(x).holder). V(x).value denotes the "current" 
value of object x which will be seen by any datastep accessing x. 

Initial State: 

a 4 = Ciy^V^, where 

Vx € obj, V (x,U) = init(x), 

V fl (x,A) = J_, VA*U. 

Events: 

8 4 = 8 3 (The sets of events are identical in Levels 3 and 4, although preconditions and transitions differ.) 

Transition Relation 

Lete € 6 4 , <T,L,V> € Z 4 , <T,L,V>e = <T1,L1,V1>. 

1. create A (A€act-{U}) 

PRECONDITIONS: 
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a. A $ @vertices L [creator(A)] 

b. parent(A) € @active L [creator(A)] 

c. (B,A) € seq, B * A =» B € @doneJcreator(A)] 
TRANSITIONS: 

a. vertice&j-j «— vertice&p U {A} 

b. status^A) ♦- 'active' 

c. @vertices L1 [creator(A)] <— @vertices L [creator(A)] U {A} 

d. @status L1 [crcator(A)KA) ♦- 'active' 

2. commit A (A € act - {U} - accesses) 
PRECONDITIONS: 

a. A € @activejA] 

b. @children L [AKA) Q ©donejA] 
TRANSITIONS: 

a. statuSy^A) ♦- 'committed' 

b. ©statuSjJAKA) <- 'committed' 

3. abort A (A€act-{U» 
PRECONDITIONS: 

a. A € ©activejA] 
TRANSITIONS: 

a. status^ A) «— 'aborted' 

b. @status u [AKA) «- 'aborted' 

4. perform A.u (A € accesses(x), u € values(x)) 
PRECONDITIONS: 
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a. A € ©activejx] 

b. A € prop-dcsc(V(x).holder) 

c. u = V(x). value 

d. anc(A) n ©abortedjx] = 

e. B € @visibleJxKA,x) => anc(A) D ABORTS^AjB) = 
TRANSITIONS: 

a. statu&j^A) <— 'committed' 

b. @status L1 [xKA) «— 'committed' 

c. label T1 (A) «— u 

d. data T1 «- data r U {(B,A): B € datasteps,<x)} U {(A,A)} 

e. Vl(x,parent(A)) <- update(AXu) 

5. (gJcreatefal A (A G act - {U}, a € loc) 
PRECONDITIONS: 

a. A € ©vertices, \fi), for some fi € loc 
TRANSITIONS: 

a. ©verticesLjto] ♦- ©verticesjo] U {A} 

b. A i @vertices L [a] =» @status L1 [aXA) *- 'active* 

6. @commitfiKl A (A € act - {U}, a € loc) 
PRECONDITIONS: 

a. A € @committcd L l/8], for some ft € loc 
TRANSITIONS: 

a. @vertices L1 [a} «- @verticesJo] U {A} 
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b. ©statuSjJaKA) «- 'committed' 

c. o € obj, V(a,A) * J_ =» 

Vl(a,A) <- _L 
Vl(o,parcnt(A)) - V(o,A) 



7. @abortf a\ A (A € act - {U}, o € loc) 

PRECONDITIONS: 

a. A € ©abortcdj/?], for some fi € loc 
TRANSITIONS: 

a. @vertices L1 [a] «— ©vcrticesja] U {A} 

b. ©statuSjJaKA) *- 'aborted' 

c. a € obj, B € desc(A) =» 

Vl(a,B)«-_L 



Local create, commit, and abort events are identical in L4 and L3. The preconditions on 
perform events are given in terms of the value map. Note that we include a "local orphan detection" 
precondition (P4.4d): this condition is necessary for the value map to hold the proper versions, but it is 
not sufficient to detect all harmful orphans. Thus we retain the non-local orphan detection precondition 
(P4.4e). 

The effect of a perform event is to update the "current" version. A lock on the current version is 
held by the parent of the datastcp immediately after the perform event The value map is updated by 
commit and abort messages: a commit message for an action releases a lock held by that action to its 
parent (and the parent inherits its child's version). An abort message for an action releases all locks held 
by descendants of that action (and the versions are discarded). 
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8.2 Specification of Mapping h 43 



We define a (single-state) mapping from L4 to L3, h 43 : L4 -*• L3. (We abbreviate "h 43 " as "h" 
in this chapter.) 

State Mapping 

h: 2 4 -► 2 3 is defined by h(<T,L,V>) = <T,L> V<T,L,V> € Z 4 . Thus h fixes <T,L>. 

Event Mapping 

h: 8 4 -* 8 3 is the identity mapping on events, i.e. h(e) = e Ve € 8 4 . 

8.3 Level 4 Invariants 

The following invariants relate the information in the value map, V, to the local data structure, 
L. We show these invariants relative to mapping h: Since h fixes <T,L>, all invariants and pair-invariants 
for <T,L> in L3 can be applied to the proofs (by Lemma 4.2.4.3.6). (Recall that we have shown in Lemma 
7.4.6 mat 13 and la are invariant in L3, and J3 and Ja are pair-invariant in 13.) 

Lemma 8.3.1: Let <T,L,V> € $> 4 . Then the following are invariant relative to h: 
(Vx € obj) (let M = L(x), and let = order(T)): 

a. B € V(x) =» B is live in M 

b. V(x) forms an ancestor chain 

c. V(x) ft accesses = 

d. B € datasteps M (x) =» 

B is dead in M V 3B' € anc(B) n V(x): B € visible^') 

e. B € V(x), v-prop-desc M (B) n V(x) = -» 

V(x,B) = result(x,s), where s = «visible M (B,x); 0(x)» 

f. H = V(x).holder, B € desc(H), B is live in M 
=» visible M (B,x) = visiblej^Oi^c) 
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g. B € V(x), C € datasteps M =» exactly one of following holds: 

1. C € visible M (B) 

2. C € dead M (B) 

3. 3C € prop-desc(B) D prop-anc(C) D V(x): 
(C € visible M (C)) A (C € visible M (B)) 

Proof: We show below that (0 and (g) follow from (a) - (e). It is trivial to show that (a) - (e) 
are 0-invariant (i.e. that they hold for <r 4 ). The proofs that (b) and (c) are invariant relative to 
h are straightforward; we will argue (a), (d), and (e). 

For the induction step, let <T,L,V> € % A f~l PRE 5 (e), and assume that (a) - (g) hold for 
<T,L,V>. Let <T\L\V> = <T,L,V>e. Let = order(T), 0' = orderCT), M = L(x), M' = 
L'(x). We must show that (a), (d), and (e) hold for <T,L',V'>. By Lemma 4.2.4.3.6, we can 
assume that <T,L,V> and <T,L\V> satisfy any invariants from 13 or la, and we can assume 
that (<T,L,V>,<T\L\V'>) satisfy any pair-invariants from J3 or Ja. 

Since properties (a), (d), and (e) depend only on V(x), committed M , aborted M , and O(x), we 
need only consider events, e, which modify these components. By inspection, these events are 
{abort A, perform A,u: A € accesses(x)} U {@commitfx] A, @abort(x] A}. 

1. abort A, A € accessesfx) 

aborted M , = aborted^ U {A}. 
committcd M . = committed... 
V = V, 0" = 0. 

a. B € V(x) » B € V(x), => B is live in M (by (a)). 
But by (c), V(x) n accesses = 0, 
=» B i accesses, -» anc(B) n {A} = 0, «» B is live in M'. 

d. B € datasteps^x) »=» B € datastep$ M (x), 

-» B is dead in M V 3B' € anc(B) n V(x): B € visible^*). But 
B is dead in M =» B is dead in M' by 73.1b. 
B' € anc(B) n V(x) «» B' € anc(B) n V(x), and 
B € visible^B') =» B € vtsibli^^B'X by 7.3.1c. 
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e. Immediate since all components unchanged. 



2. perform A,u, A € accesses(x) 

O'(x) = O(x) U {(B,A): B € datasteps M (x)} U {(A,A)}. 

V'(x,parent(A)) = update(AXV(x). value). 

V'(x,B) = V(x,B) VB * parent(A). 

V(x) = V(x) U {parent(A)}. 

committed M . = committedj^ U {A}. 

aborted M , = aborted M (thus live in M =» live in M'). 

Note that A € prop-dcsc(V(x).holder), by P4.4b, and A is live in M, by P4.4d. 

a. B € V'(x) => B € V(x) V B = parent(A). 
If B € V(x), then B is live in M, so B is live in M\ 
If B = parent(A), then anc(B) C anc(A), and A is live in M. Thus B 
is live in M, and B is live in M\ 

d. B € datasteps^x) => B € datasteps M (x) V B = A 

If B € datasteps M (x), then B is dead in M V 3B' € anc(B) f*l V(x): 
B € visible^B'). 

If B is dead in M, then B is dead in M' by 7.3.1b. 

If B' € anc(B) PI V(x), then B' € anc(B) n V'(x), and B € 

visible M (B') =» B € visible M .(B*) by 73.1c. 

If B = A, then take B* = parent(A), because parent(A) € anc(A) PI 
V'(x), and A € visible M Xparent(A)). 

e. B € V'(x), v-prop-desc M ,(B) fl V(x) = 0. 
B € V'(x) =* B € V(x) V B = parent(A). 

Casel: B€V(x). 

v-prop-desc M (B) C v-prop-desc^B), and V(x) C V(x) 
=> v-prop-desc M (B) n V(x) = 0. 

Thus V(x,B) = V(x,B) = resuh(x,s), where s = «visible M (B,x); 
0(x)». 

We must show V'(x,B) = results'), where s' = «visible M ,(B,x); 
0'(x)». Since 0(x) Q 0'(x), it suffices to show visible M XB,x) = 
visible M (B,x). Since A is the only action whose status changes from 
M to M\ visible M <B,x) = visible M (B,x) unless A € visible M <B,x). 
So assume A € visible M ^B,x). 

Since parent(A) € desc(V(x).holder) (by P4.4b), parent(A) € 
prop-desc(B) (since we assumed B * parent(A)). But A € 
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visible M <B,x) =» parent(A) € v-prop-desc M ,(B) (~) V'(x) -- a 
contradiction. 

Case 2: B = parent(A). 

If B = parenKA), then V'(x,B) = updatc(AXV(x).value). 

Let H = V(x).holder. Then by definition of holder 

v-prop-desc M (H) (~\ V(x) = 0. Thus V(x,H) = result(x,s), where s 
= «visible M (H,x); 0(x)», => V'(x,B) = result(x,s'), where s' = 
«visible M (H,x) U {A}; 0'(x)». 

We must show that visible M (H,x) U {A} = visib1e M ,(parent(A),x). 
Qearly visiblc M ,(parent(A),x) = visiblc M (parcnt(A),x) U {A}, so we 
show visible M (H,x) = visible M (parent(A) t x). 

But A € prop-desc(H) =» parent(A) € desc(H), and A live in M =» 
parent(A) live in M. Thus visible M (H,x) = visible M (parent(A),x), 

by(0. 



3. @commit[x]A 
There are two cases: 

(l)IfV(x,A)*_|_,then 

V'(x) = V(x)- {A} U {parent(A)}, 

V(x,A) = J_. 

V(x,parent(A)) = V(x,A). 
(2) If V(x,A) = JL, then V(x) = V'(x). 

committed M . = committcd M U {A}. 

aborted^ = aborted M (thus live in M ==» live in M'). 

datasteps^x) = datastcps M (x), since A € accesses(x) ==» A € 
@committed L [/3], for some fi, by P4.6a, =» A € committedj. by Lemma 7 J.2f, 
=» A € @committcd M , by Lemma 7 J.2b. 

a. For case (1), B € V'(x) =» B € V(x) -» B is live in M -» B is live 
inM\ 

For case (2), B € V'(x) -» B € V(x) or B = parenKA). If B € V(x) 
then the proof is identical to case (1), otherwise we know A € V(x), 
and A is live in M. It follows that B is live in M =» B is live in M\ 

d. B € datasteps^x) =» B € datasteps M (x) 

=»BisdeadinMV3B'€ anc<B) O V(x): B € visible^'). 

If B is dead in M then B is dead in M\ so suppose that B' € anc(B) 
V(x). 
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For case (1), V(x) = V(x), => B' € anc(B) H V'(x), and B € 
visible M (B') => B € visible^B'). 

For case (2), A € V(x), and V'(x) = V(x) - {A} U {parent(A)}. 
If B' * A, then B' € anc{B) D V'(x) and B € visible^') as above. 

If B' = A, then B € visible^A), and A € visible M ^parent(A)) (since 

A € committed^. 

Thus B € visible M ,(parent(A)), and parent(A) € anc(B) n V'(x). 

e. B € V'(x), v-prop-desc M .(B) n V'(x) = 

Case 1: A € V(x), => V'(x) = V(x) - {A} U {parent(A)}. Thus B 
*A. 

Case la: B * parent(A). 

=» B € V(x). But v-prop-desc M (B) C v-prop-desCj^B), and V(x) - 
{A} C V'(x). Thus (V(x) - {A}) n v-prop-desc M (B) = 0. • 

But if A € v-prop-dcsc M (B) and B * parent(A), then parent(A) € 
v-prop-desc M (B) D V'(x) - a contradiction. Thus v-prop-desc M (B) 
PI V(x) = 0. 

Thus V(x,B) = V'(x,B) = result(x,s), where s = «visible M (B,x); 

0(x)». 

We show that visible M (B,x) = visible M XB,x). Clearly visible M (B,x) 

C visible M ,(B,x). Let D € visible^XB.x) - visible M (B,x); we show 

that the existence of D leads to a contradiction. 

We apply (g) to D and B: We cannot have D € visible M (B) by our 
assumption. If D € dead M (B), then D C visible^B) ~ a 
contradiction. Thus we are left with the third case: 3D' € 
prop-desc(B) n prop-anc(D) n V(x): (D € visible^D')) A (D* € 
visible M (B))). 

D € visible M .(B) =» D' € v-prop-desc M .(B). But if D' * A, then D* 
€ V(x) n v-prop-desc^B) - a contradiction. If D* - A, then 
parent(A) € V(x) n v-prop-desc M .(B) ~ a contradiction. 

Case lb: B = parent(A). 

v-prop-desCj^A) C v-prop-desc^A) CJ v-prop-desc M .(parent(A)), 
since A € visible M .(parent(A)), and V(x) Q V(x) U {A}. Thus 
v-prop-desCj^CA) C\ V(x) = 0. 

Thus V(x,A) = V(x,parent(A)) = result(x,sX where s = 
«visible M (A,x); 0(x)». But visible M ,(parent(A),x) = visible^A^) 
(since A € committed M ), and 0'(x) = 0(x). 
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Case 2: A € V(x), *• V'(x) = V(x). Thus B € V(x). 
v-prop-desc M (B) C v-prop-desc M .(B), =► v-prop-desc M (B) n V(x) 
= 0. Thus V(x,B) = V'(x,B) = results), where s = 
«visible M (B,x); 0(x)». We must show visible M (B,x) = 
visible^B^). Clearly visible^x) C visible M .(B,x). Let D € 
visible M XB,x) - visible M (B,x); we show that the existence of D leads 
to a contradiction. 

As in case (la), we apply (g) to D and B; the only possible case is the 
third: 3D' € prop-desc(B) n prop-anc(D) fl V(x): (D € 
visible M (D')) A (D' € visible^))). 

But D € visible M ,(B) -» D' € visible M <B) PI V(x) - a 
contradiction. 



4. @abort[x]A 

V'(x) = V(x)-desc(A). 
B € V'(x) => V'(x,B) = V(x,B). 
committed M , = committed,^ 
aborted M , = aborted M U {A}. 
O'(x) = 0(x). 

a. B € V(x) =» B € V(x), B $ desc(A). Thus anc(B) n abortec^ = 
0, =» anc(B) n aborted M . = 0, since B I desc(A) and aborted^ 
= aborted M U {A} . Thus B is live in M\ 

d. B € datasteps^x) =» B € datasteps M (x) =* B is dead in M V 
3B' € anc(B) D V(x): B € visible^B'). 

If B is dead in M, then B is dead in M\ 

If B' € anc(B) n V(x), and B' C desc(A), then B' € anc(B) n V(x), 
and B € visible M ^B') since B € visiblej^B'). 

If B' € desc(A) then B € desc(A), =* A € anc(B) fl aborted^ >• 
Bis dead in M\ 

e. B € V(x), v-prop-desc M .(B) fl V(x) = 0, 
-» B € V(x), and B C desc(AX 

Suppose C € v-prop-desc^B) n V(x); then C € v-prop-dest^B) 
n V(x), -• C € desc(A) (since V(x) = V(x) - desc(A)). 
But B € desc(A), so A € prop-desc(B) n anc(C). Then C f 
visiblej^tB)- a contradiction. 
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Thus v-prop-desc M (B) (1 V(x) = 0, =» V(x,B) = V'(x,B) = 
result(x,s), where s = «visible M (B,x); 0(x)» = «visible M .(B,x); 
0'(x)». 



Proof of (g): First we show that at least one of the three conditions must hold: 

B € V(x), C € datastcps^ But by (d), either C is dead in M, or 3C € anc(C) D V(x): C € 
visible^C). 

If C is dead in M, then either C € dead M (B), or ka(B,C) is dead in M. But if lca(B,C) is dead 
in M, then B is dead in M, which contradicts (a). Thus we have case (g2). 

So suppose 3C € anc(C) D V(x): C € visible M (C). If C € visible M (B), then C € 
visible M (B), which is case (gl). If C C visible M (B), then (B,C) € related, since V(x) forms an 
ancestor chain (by (b)). But if C € anc(B), then C € visible M (B). Thus C € prop-desc(B) C\ 
prop-anc(C) n V(x), which is case (g3). 

To see that only one condition can hold, it is clear that (gl) and (g2) are mutually exclusive, 
and that (gl) and (g3) arc mutually exclusive. If (g3) holds, then C € visible M (C), and C € 
V(x). But by (a), C must be live in M, so C must be live in M; thus C € dead M (B). Thus (g2) 
and (g3) are mutually exclusive. 

Proof of (f): H = V(x).holder, B € desc(H), B is live in M. We show visible M (B,x) = 
visible M (H,x). Since B € desc(H), it is obvious that visible M (H,x) Q visible M (B,x). If B = H 
then the result is obvious, so assume B € prop-desc(H). Suppose D € visible M (B,x); we show 
D € visible M (H,x). LetL = fca(B,D). 

D € visible M (B,x) =► D € visible M (L), =» L € prop-desc(H), since D t visibl^fH). 

Now we apply (g) to D and H: If (g2) holds, then D is dead to H. But since B is live in M, L 
is not dead to H; thus D must be dead to B. But D € dead M (B) contradicts D € visiblc^B). 

(g3) cannot hold, because by definition of holder there is no D' € prop-desc(H) O V(x). 

Thus (gl) must hold, =» D € visible^H). I 
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8.4 Proof of Possibilities Map for h 4J 

We now show that h is a possibilities map. Let 14 be the conjunction of all properties in Lemma 
8.3.1. We will show that h is a possibilities map relative to 14. 

Lemma 8.4.1: h preserves initial states. 

Proof: Immediate, since h(<T ,L ,V >) = <T Q ,l^>. I 

Lemma 8.4.2: h preserves transitions relative to 14. 

Proof: We must show that if <T,L,V> € PRE 4 (e) fl & 4 n 14. and h(<T,L,V>) € PRE 3 (h(e)) 
n % y then h(<T,L,V>e) = h(<T,L,V>)h(e). 

But h(<T,L,V>) = <T,L> and h(e) = e, so we must show the following: 

If <T,L,V> € PRE 4 (e) f) & 4 (1 14, and <T,L> € PRE 3 (h(e)) H 9> 2 , and <T,L,V>e = 
<Tl,Ll,Vl>,then<Tl,Ll> = <T,L>e. 

It is easily verified by inspection that the effects of all events on T and L are identical in L3 
and L4; thus h preserves transitions relative to 14. I 

Lemma 8.4.3: h preserves preconditions relative to 14. 

Proof: We must show that if <T,L,V> € PRE 4 (e) n & 4 n 14, and h(<T,L,V>) € <% y then 
h«T,L,V>) € PREj(h(e)). 

Since h(<T,L,V>) = <T,L>, and h(e) = e, we must show 

<T,L,V> € PRE 4 (e) n» 4 n 14, <T,L> € & 3 -» <T,L> G PRE^e). 

Preservation of preconditions is easily verified by inspection for all events other than perform, 
since preconditions are identical in L3 and L4. 

We prove preservation of preconditions for event e = perform A,u: 
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a. P4.4a =» A € ©activejx]. 

b. B € ©datastcpsJxKx) -» B is dead in L(x) V 3B' € anc(B) V(x): B € 
©visibleJxKB'), by 8.3.1d. 

If B is dead in Ux), then anc(B) n ©aborted Jx] * 0. But P4.4d =» anc(A) n 
©abortedjx] = 0, =» anc(lca(A,B)) n ©abortedjxj = 0. 

Thus anc(B) n prop-desc(lca(A,B)) n ©abortedjx] * 0, =» B € 
©deadJxKA). 

If B' € anc(B) n V(x), then B' € anc(V(x).holder). 

But A € prop-desc(V(x).holder) by P4.4b, =» A € prop-desc(B'). 

Thus B € ©visibleJxKB') -» B € ©visible JxKA), by Lemma 2.2.3.1d. 

c. P4.4c => u = V(x). value. LctH = V(x).holder (thenu = V(x,H)). 

By 8.3.1e, V(x,H) = result(x,s), where s = «@visibleJxKH,x); 0(x)». 

But A € prop-desc(H) by P4.4b, and A is live in L(x) by P4.4d, 
=» @visible L lxKH,x) = @visible L lx](A,x), by 83.1f. 

Thus u = results'), where s' = «@visible L [x](A,x); 0(x)». 

d. B € @visiblc L [xKA,x) =» anc(A) n ABORTS^AiB) = 0, directly by P4.4e. 
I 



Lemma 8.4.4: h is a possibilities map relative to 14. 

Proof: Follows immediately from Lemmas 8.4.1, 8.4.2, 8.4.3, and from Lemma 4.2.4.2.4. I 

Theorem 8.4.5: h is a possibilities map, and 14 is invariant in L4. 

Proof: By Lemma 8.3.1, 14 is invariant relative to h. By Lemma 8.4.4, h is a possibilities map 
relative to 14. We apply Lemma 4.2.4.2.6 to conclude that h is a possibilities map, and 14 is an 
invariant I 

Since h 4J is a possibilities map which fixes <T,L>, all invariants and pair-invariants from L3 
carry down to L4. In the following Lemma we summarize all the known invariants and pair-invariants for 
L4: 
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Lemma 8.4.6: la, 13, and 14 arc invariant in 1.4, and Ja, J3 arc pair-invariant in L4. 

Proof: Invariancc of 14 is shown in Theorem 8.4.5. Since h 43 is a possibilities map which 
fixes <T,L>, and la, 13 are invariant in 1.3, la and 13 arc invariant in 1.4, by Lemma 4.2.4.3.5. 
Similarly since Ja, J3 are pair-invariant in 1.3, Ja and J3 arc pair-invariant in L4, by Lemma 
4.2.4.3.5. I 
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9. Fully Localized Models 

At Level 5 we completely localize all preconditions by "piggybacking" abort information on 
communications steps. This additional information flow allows us to replace the orphan detection 
precondition (P4.4c) with a local check for orphans. Other than the new abort information in 
communication steps (and the elimination the non-local orphan precondition), Level 5 is identical to 
Level 4. 

Because all preconditions are localized at Level 5, we can project out the "virtual" global state to 
define Level 6. 

9.1 Level 5 Algebra 

L5 = (8 5 ,2 5 ,a 5 ,T 5 ) 

State Space: 

2, = 2 4 = {<T,L,V>}, where the components are: 

T - the global state, an augmented action tree (as in L2), 
L - localUAS's(asinL3), 
V - value maps (as in L4). 

Initial State: 

ff 5 = a 4 = <T ,L ,V >. 

Exeats 

The local steps are identical in L5 and L4, but for the communications events we introduce an 
explicit "sender" of information. (Thus communications events are now parameterized by two locations: 
the sender and the receiver.) This modification is necessary to describe precisely the set of aborts which 
must be piggybacked on a communications event (In fact this set will be all aborts known to the sender). 

Communications events: 
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@create[/S,a] A,d • - send create message from fi to a with aborts d 
©committer] A,d -- send commit message from fi to a with aborts d 
@abort{/?,a] A -- send abort message from fi to a 

The parameter "d" of create and commit messages models the DONE lists in remote invocation and 
commit messages. 

As in previous levels, the transition relation will be defined so that each communications event is 
idempotent 

Transition Relation 

Let e € « 5 , <T,L,V> € 2 5 , <T,L,V>e = <T1,L1,V1>. 

1- create A (A€act-{U» 

PRECONDITIONS: 

a. A C @vertices L [creator(A)] 

b. parent(A) € @activeJcreator(A)l 

c. (B,A) €seq,B*A=»B€ @doneJcreator(A)J 
TRANSITIONS: 

a. verticesyj ♦- verticeSj. U {A} 

b. status^ A) «- 'active' 

c. ©verticesLjlcreatoKA)] ♦- @verticesJcreator(A)] U {A} 

d. ©statuSjJcreatorMKA) ♦- 'active' 

1 commit A (A € act -{U}- accesses) 

PRECONDITIONS: 
a. A € ©activeJA] 
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b. @childrcnjAKA)C@done L [A] 
TRANSITIONS: 

a. status^A) ♦- 'committed' 

b. @status u {AKA) ♦- 'committed' 

3. abort A (A€act-{U» 
PRECONDITIONS: 

a. A € @activejA] 
TRANSITIONS: 

a. statu&j-jCA) ♦- 'aborted' 

b. @status u [AKA) ♦- 'aborted' 

4. perform A.u (A € acccsses(x), u € values(x)) 
PRECONDITIONS: 

a. A € @active L [x] 

b. A € prop-desc(V(x).holder) 

c. u = V(x). value 

d. anc(A) D ©abortedjx] = 
TRANSITIONS: 

a. status^ A) «— 'committed' 

b. @status u [xKA) «- 'committed' 

c. label^A)*— u 

d. data^ <- data,. U {(B,A): B € datasteps^x)} U {(A,A)} 

e. Vl(x,parent(A)) *- update(AXu) 
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5. ©createfff .a] A.d (A € act - {U}, p,a € loc, d C act) 
PRECONDITIONS: 

a. A € @active L D5] 

b. d = @aborted L (/3] 
TRANSITIONS: 

a. ©verticeSjJa] «- @verticesja] U {A} 

b. A C @verticesja] =» ©statuSjJaKA) 4- 'active' 

c. ©abortedj Jo] «- ©abortedjo] U d 

d. o € obj, D € d, B € desc(D) =» 

Vl(a,B)-_|_ 

6. @£2®sM&sHM (A€act-{U},/3,a€loc, dCact) 
PRECONDITIONS: 

a. A € @committedJ0] 

b. d = @aborted L |j8] 
TRANSITIONS: 

a. @vertices L1 {a] *- ©vertices Ja] U {A} 

b. ©status^aKA) «- 'committed' 

c. a € obj, V(a A) * _L -» 

Vl(a,A)-J_ 
Vl(a,parent(A)) «- V(o,A) 

d. @aborted L1 (a] <- @aborted L [o] U d 

e. a € obj, D € d, B € desc(D) >• 

Vl(a,B)-J_ 

7. ©abortffl.al A (A € act - {U}, fi,a € loc) 
PRECONDITIONS: 
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a. A € ©abortedj/?] 
TRANSITIONS: 

a. @vertices L1 [a] <— ©verticesja] U {A} 

b. @status u [oKA) *- 'aborted' 

c. a € obj, B € desc(A) =» 

Vl(a,B)-_L 



The preconditions and transitions for all local events are identical in L5 and L4 (except that the 
non-local orphan detection precondition, P4.4e, is eliminated at Level 5). Communications events are 
fundamentally different at Level 5, since orphan detection information is explicitly passed between 
locations with create and commit messages. 

The orphan information that we include with create and commit messages is quite simple: a 
sending location must piggyback all the aborts it knows about onto these messages. These messages now 
correspond closely to the create and commit messages of the simplified orphan detection algorithm that 
we presented in Chapter 1. The "known aborts set" in these messages models the "DONE" list in the 
messages of this algorithm. While we show below that this information is sufficient (because there is a 
possibilities map from L5 to L4), other choices are possible. As a simple example, we conjecture that it is 
only necessary to send a covering subset of the known aborts in create and commit messages, because such 
a subset captures the same information about potential orphans. We have not attempted to take such 
optimizations into account, and we have focused on simplicity of description for our model. In general, at 
every level of our algebra hierarchy we make additional choices about the details of our model, and we 
further restrict the possible implementations which fit this model. 

In our Level 5 model we do not piggyback the known aborts set onto abort messages. We can 
explain the difference between abort messages and create or commit messages by recalling (from Chapter 
3) that in our idealized transaction system, aborts transfer no information (other than the fact that the 
abort occurred). Because the receiver of an abort message docs not "learn anything" about the execution 
history, the sender need not tell the receiver about all potential orphans. Internal consistency is achieved 
by coupling the flow of normal information with the flow of orphan information. (In this case "orphan 
information" is just the set of known aborts at the sender.) Of course, it would not hurt to piggyback 
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known aborts onto abort messages, and this additional information might allow some orphans to be 
detected sooner. 

9.2 Specification of Mapping h^ 

We define a (single-state) mapping from L5 to L4, h^: L5 -* LA (We abbreviate "h^" as "h" 
in this chapter.) 

State Mapping 

h: 2 5 - 2 4 is the identity mapping: h(<T,L,V>) =<T,L,V> V<T,L,V> € 2 5 . Thus h fixes <T,L,V>. 

Event Mapping 

h: 8 5 -*■ 8 4 is defined as follows. Let ord4 be an arbitrary total order on 8 4 , and let aborts-in(d) = 
{@abora>] D: D € d}. 

h: create A -*■ create A 

commit A -♦ commit A 

abort A -* abort A 

perform A,u -* perform A,u 

@create(/?,a] A,d -*■ @create[o] A • «aborts-in(d); ord4» 
@commitl/S,o] A,d -* @commit[o] A • «aborts-in(d); ord4» 
@abort|)9,o] A -♦ @abort[a] A 

Note that we map communications events ©create and ©commit into a sequence of events at Level 4. 
This sequence first creates or commits the primary action in the message, and men effectively aborts all 
actions in the aborts list, d. We will show that the order in which these abort events occur is unimportant; 
thus we let ord4 be an arbitrary order. 
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9.3 Level 5 Invariants 

Before stating the Level 5 invariants, we state two preliminary lemmas which will be used 
below: 

Lemma 9.3.1: Let <T,L,V> € 9t> 5 D PRE 5 (e), and <T,L\V> = <T,L,V>e. Suppose that 
<T,L,V> satisfies 13, and (<T,L,V>,<T,L\V>) satisfies Ja and J3. If ABORTS^A) < 
©abortedjo], and A € ©committedjet], then 

ABORTS T .(A) < @aborted L ,[a]. 

Proof: If A € ©committedja], then by Lemma 7.3.2f, A € committedp 
=» ABORTS T ,(A) < ABORTS T (A), by Lemma 6.3.3 J. 

But ©abortedjot] C @aborted L ,[a], by Lemma 7.3.1a => ©abortedja] < @aborted L ,[a], 
by Lemma 2.2.1.1a. 

And ABORTS^A) < ©abortedja], by hypothesis. 

Thus ABORTS r (A) < ©abortedja], by transitivity of <. I 

Lemma 9.3.2: Let <T,L,V> € * 5 D PRE 5 (e), and <T,L\V> = <T,L,V>e. Suppose that 
<T,L,V> satisfies 13, and «T,L,V>,<T\L\V'» satisfies Ja and J3. If SEQ- ABORTS^ A) < 
©abortedja]. and A € ©active Ja], then 

SEQ-ABORTS T ,(A) < ©aborted^]. 

Proof: If A € ©active Ja], then by Lemma 7.3.2f, A € vertice&p 
=> SEQ-ABORTS^A) < SEQ-ABORTS^A), by Lemma 6.3.3.4. 

But ©abortedja] C @aborted L .[«], by Lemma 7.3.1a =» ©abortedjo] < ©aborted^], 
by Lemma 2.2.1.1a. 

And SEQ-ABORTS^A) < ©abortedja], by hypothesis. 

Thus SEQ-ABORTSp(A) < ©abortedja]. by transitivity of <. I 
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The following invariants are our key result for Level 5. They express the fact that the local states 
have the proper abort information at all times. We show these invariants relative to mapping h: Since h 
fixes <T,L,V>, all invariants and pair-invariants in L4 can be applied to the proofs (by Lemma 4.2.4.3.6). 
(Recall that we have shown in Lemma 8.4.6 that 14, 13, and la are invariant in L4, and J3 and Ja are 
pair-invariant in L4.) 

Lemma 9,3.3: Let <T,L,V> € 3> 5 . Then the following are invariant relative to h: 

(Va € loc) 

a. A € ©committedja] => ABORTS^A) < ©abortedja] 

b. A € ©activeja] => SEQ-ABORTS^A) < ©abortedja] 

Proof: It is trivial to show that (a),(b) are O-invariant (i.e. that they hold for a 5 ): (a) holds 
vacuously, and for (b) only U € ©vertices, [o], but SEQ- ABORTS,. = 0. 

For the induction step, let <T,L,V> € % 5 n PRE 5 (e), and assume that (a),(b) hold for 
<T,L,V>. Let <T\L\V> = <T,L,V>e. We must show that (a),(b) hold for <T\L\V'>. By 
Lemma 4.2.4.3.6, we can assume that <T,L,V> and <T\L\V'> satisfy any invariants from 14, 13 
or la, and we can assume that (<T,L,V>,<T,L',V>) satisfy any pair-invariants from J3 or Ja. 

Using the Induction Hypothesis, and invariants 13, J3, Ja, we can apply Lemmas 9.3.1 and 
9.3.2 to conclude that 

A € ©committedja] =» ABORTS r (A) < ©abortedja]. 

A € ©activeja] => SEQ-ABORTS r (A) < ©abortedja]. 

Thus we need only show that (a) holds (respectively, (b) holds) for <T\L\V> where A € 
©committed^] - ©committedjo] (respectively, A € ©activeja] - ©activeja]). We 
consider all possible events, e, for these remaining cases: 

1. create A (note that A * U) 

©committedja] = ©committedja]. 

©activeja] - ©activeja] = {A}, for a = creator(A). 
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©active^a] = ©activeja], for a * creator(A). 

a. Holds vacuously. 

b. (We need only consider a = creator(A).) 
By P5.1b, parent(A) € ©activejo], 

=» SEQ-ABORTS r (parcnt(A)) < @aborted L .[a]. 

By P5.1c, (B,A) € seq, B * A =» B € @donejo]. Thus B € 
v-seq r (A) =» B € ©committedja], 
=» ABORTS r (B) < @aborted L ,Io]. 

B € i-seq r (A) =» B € ©abortcdja] =► B € @aborted L> [al, 
=» i-seq r (A) < ©abortedjja]. 

Thus SEQ-ABOR TSUparentfA)) U U ABORT&UB) 
1 B € v-seq r (A) ' 

U i-seq r (A) < @aborted L .[a], by Lemma 2.2.1.1c 
Thus SEQ-ABORTS r (A) < @aborted L> [a], by Lemma 6.2.1.4. 

2. commit A (note A € accesses) 

©committcd L .[a] - ©committedja] = {A}, for o = A. 
©committedja] = ©committedja], for a * A. 
®active L ^o] Q ©activeja]. 

a. (We need only consider a — A.) 

ABORTMA) = i-precedes^A) U UaBORTS t .(B) . 
1 ' B € v-precede&j-tA) 

Since A $. accesses, v-data-anc^A) = i-data-anCp(A) = 0; thus 

v-precedes T ,(A) = v-anc-seq^A) U v-childp(A), and 

i-precedes r (A) = i-anc-seq r (A) U i-childp(A). 

Thus ABORTMA) = i-anc-seq^A) U UaBORTMB) U 
1 ' B € v-anc-ittijA) 

i-chilcUA) U UABORT&UB) . 
1 B € v-childpCA) 1 

= SEQ-ABORTVA) U i-chilcUA) U UABORTMB) . 
1 l B € v-diildpCA) 1 

But A € ©activejAJ by P5.2a, -» SEQ-ABORTS^A) < 
@aborted L .[A], by Lemma 9.3.2. 

If B € children^A), then B € children^A). But by Lemma 7.3 .2a, 
B € children^A) -» B € ©verticesjAl. By P5Jb, 
@childrenjAKA) C ©donejA]. From Lemma 7.3.2f, it follows 
that v-child r (A) C ©committedjjA], and i-child^A) C 
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©abortedJA]. 

Thus B € v-child,,(A) =» ABORTC^B) < @aborted L .[A], by 
Lemma 9.3.1. 

B € i-child^A) => B € ©abortedJA] => B € ©abortedJA], by 
Lemma 7.3.1a. 

Thus we have shown 
SEQ-ABORTS r (A) < ©abortedJA], 
i-child r (A) < ©aborted L ,[A], and 

yABORTS T ,(B) < ©aborted, ,[A]. 
v-child^A) 1 L 

ABORTS r (A) < @aborted L ,[A] follows directly from Lemma 
2.2.1.1c. 

b. Holds vacuously. 



3. abort A 

@committed L .[a] = ©committedja] 
@active L Ja] C ©activeja] 

a. Holds vacuously. 

b. Holds vacuously. 

4. perform A,u 

@committcd L ,[o] - ©committedja] = {A}, foro = x (x = object(A)) 
@committed L ,[o] = ©committedja], fora * x 
@active L .fa] C ©activeja] 

a. (We need only consider a = x) 

ABORTMA) = i-precedeMA) U UABORTMB) ■ 
1 ' B € v-precede&jJtA) 

Since A € accesses, v-childj,(A) = i-childpCA) = 0; thus 

v-preccde& r (A) = v-anc-seq^A) U v-data-anCpCA), and 

i-precedeSpCA) = i-anc-seq-^A) U i-data-anc^A). 

Thus ABORTMA) = i-anc-seqJA) U U ABORTS~(B) U 
1 ' B € v-anc-sec^A) 

i-data-anc^A) U UABORTMB) . 
B t v-data-anCptA) 

= SEQ-ABORTMAJU i-data-ancUA) U UABORTMB) . 
1 ' B € v-data-inCptA) 
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But A £ ©activejx] by P5.4a, => SEQ-ABORTS r (A) < 
@aborted L .[x], by Lemma 9.3.2. 

If (B,A) € v-dat&p then B € @visible L Jx](A), by Lemma 7.3 2}, =» 
B € ©visibleJxKA). 

Thus AjB € ©committedjx], =» ABORTS r (AiB) < 
@aborted L .[x], by Lemma 9.3.1. 

If (B,A) € i-datap, then B € @dead L ,[x], by Lemma 7.3.2k. But B € 
@dead L .[x] =» {crucial r (B)} < @aborted L .[xJ, by Lemma 7.3.21. 

Thus we have shown 
SEQ-ABORTSpfA) < @aborted L .[x], 
i-data-anc r (A) < @aborted L .[x], and 

VABORTS T .(B) < ©aborted, .[x]. 
v-data-ancptA) 

ABORTS T (A) < @aborted L ,[x] follows directly from Lemma 
2.2.1.1c. 

b. Holds vacuously. 



5. @create[/},a] A,d 

@committed L .[y] = ©committedjy]. 

©verticeSjJy] = ©verticesj-y] U {A}, for y - a (unchanged for all other 

locations). 

<5:active L Ja] - ©activejo] C {A} (might be 0). 

©actively] = ©activejyj, for y * a. 

a. Holds vacuously. 

b. (We need only consider y = a.) 

By P5.5a, A € ©acuvejfl; thus SEQ-ABORTS^A) < 
@aborted L l/5], by Lemma 9.3.1. 

But d = @abortcd L |0] by P5.5b, and d C ©abortedjjal (by 
TSSc). Thus SEQ-ABORTS^A) £ @aborted L .|al. 

But A € ©activej/*] -» A € vertkeSj. by Lemma 7.3.2f, =» 
SEQ-ABORTS T (A) < SEQ- ABORTS^ A), by Lemma 6J.3.4. 

Thus SEQ-ABORTS r (A) < @aboited L 4ol, by transitivity of <. 
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6. @commit[/J,a] A,d 

©committedj .[a] - ©committedj [a] C {A}. 
@committed L ,[-y] = ©committedjyj, for y * a. 
@active L ,[-y] C ©activcjy]. 

a. (We need only consider y = a.) 

By P5.6a, A € ©committed^]; thus ABORTS^A) <J 
@aborted L [0], by Lemma 9.3.1. 

But d = @abortedJ/8] by P5.6b, and d C @aborted L> [o] (by 
T5.5d). Thus ABORTS^A) < @aborted L ,[o]. 

But A € @committed L |/*] =» A € committedj. by Lemma 7.3.2f, 
=» ABORTS r (A)< ABORTS.j<A), by Lemma 6.3.3.3. 

Thus ABORTS r (A) < @aborted L ,[o], by transitivity of <. 

b. Holds vacuously. 



7. @abort|)5,o]A 

@committed L .[y] = ©committedjy]. 
©actively] C ©activejyj. 

a. Holds vacuously. 

b. Holds vacuously. I 



9.4 Proof of Possibilities Map for h^ 

We now show that h is a possibilities map. Let IS be the conjunction of all properties in Lemma 
9.3.3. We will show that h is a possibilities map relative to 15. 

Lemma 9.4.1: h preserves initial states. 

Proof: Immediate since h«T ,L ,V >) = CT^L^V^. I 

Lemma 9.4.2: h preserves transitions relative to IS. 
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Proof: We must show that if <T,L,V> € PRE 5 (c) fl * 5 n 15, and h(<T,L,V>) € PRE 4 (h(e)) 
n % A , then h«T,L,V>e) = h(<T,L,V>)h(e). 

But h(<T,L,V>) = <T,L,V>, so we must show the following: 

Let<T,L,V> € PRE 5 (e) fl $> 5 n PRE 4 (h(e)) n «fc 4 . 

Let<T,L,V>e = <T1,L1,V1> (in L5), <T2,L2,V2> = <T,L,V>h(e) (in L4). 

Then<Tl,Ll,Vl> = <T2,L2,V2> 

For the local steps (create, commit, abort, perform), h(e) = e, and it is easily verified by 
inspection that the effects of these events on T, L, and V are identical in L5 and L4. It is also 
easily verified by inspection that the effect of @abort[/9,a] A is identical to the effect of 
@abort[a] A. 

For communications events ©create and ©commit, transition steps T5.5a,b, and T5.6a,b,c 
are identical to transition effects T4.5a,b, and T4,5a,b,c, respectively. Transition steps 
T5.5c,d, and T5.6d,e, respectively, accomplish the same effect as the sequence of aborts 
«aborts-in(d); ord4»: Adding all aborts in d to ©abortedjo] (Level 5) has the same effect 
as adding them individually (Level 4). To see that updating of value maps is also preserved, 
note that an abort at an object removes all descendants of the aborted action from the value 
map at that object. But individually removing descendants of each action (Level 4) has the 
same effect as removing all descendants from actions in d at once (Level 5). Note that this 
removal of descendants is clearly commutative, and thus the order of abort steps in 
aborts-in(d) makes no difference. I 

Lemma 9.43: h preserves preconditions relative to IS. 

Proof: We must show that if <T,L,V> € PRE 5 (e) n & 5 n 15, and h(<T,L,V>) € ffc 4 , then 
h«T,LV>) € PRE 4 (h(e)). 

Since h«T,L,V>) = <T,L.V>, we show 

<T,L,V> € PRE 5 (e) n * 5 n 15 n 5b 4 =» <T,LV> € PRE 4 (h(e)). 

Preservation of preconditions is easily verified by inspection for all local steps other than 
perform, since preconditions are identical in L5 and L4. We prove preservation of 
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preconditions for event- e = perform A,u, and for the communications steps: 

1. perform A,u 

a. P5.4a «=> P4.4a. 

b. P5.4b « P4.4b. 

c. P5.4c « P4.4c. 

d. P5.4d ~ P4.4d. 

e. B € @visibleJxKA,x) =» AJB € ©committedjx] 

-» ABORTS^ AiB) < ©abortedjxj by Lemma 9.3.3a. 

But by P5.4d, anc(A) n ©abortedjx] = 0. Thus anc(A) D 
ABORTS^AIB) = 0, by Lemma 2.2.1.1d. 



2. e = @creatc|/J,a] A,d 
h(e) = @create[a] A • «aborts-in(d); ord4» 

First we show that <T,L,V> € PRE 4 (@create[a] A): 

a. P5.5a =» A € ©activeJjS], =» A € ©verticesJ/S], which 
automatically satisfies P4.5a. (P4.5a requires that there be somefl for 
which A € ©verticesJ/H) 



Now let e' be the prefix of h(e) preceding @abort[a] D (where D € d), and let 
<T1,L1,V1> = <T,L,V>e' (in L4). We show that <T1,L1,V1> € PRE 4 (@abort[a] 

D): 

a. D € d =» D € @aborted L [0] =» D € abortedj. by Lemma 7 3.2f, 
=> D € ©abortedJD] by Lemma 7.3.2c, 
=» D € @aborted L1 [D] by Lemma 7.3.1a. 



3. @commit(/J,a] A,d e = ©committer] A,d 
h(e) = @commit(a] A • «aborts-in(d); ord4» 

First we show that <T,LV> € PRE 4 (@commitfa] A): 

a. P5.6a =» A € @committed L [/S], which satisfies P4.6a. 



Now let e' be the prefix of h(e) preceding @abort[a] D (where D € d), and kt 
<T1,L1,V1> = <T,L,V>e' (in L4). We show that<Tl,Ll,Vl> € PRE 4 (@aboru>] 
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D): 



a. D € d =» D € @abortcdJ/3] -» D € aborted^ by Lemma 7.3.2f, 
=» D € ©abortedJDJ by Lemma 7.3 2c, 
=> D € @aborted u [D] by Lemma 7.3.1a 

4. ©abortfjM A 

a. P5.7a => A € ©abortedJ/J], which satisfies P4.7a. I 



Lemma 9.4.4: h is a possibilities map relative to IS. 

Proof: Follows immediately from Lemmas 9.4.1, 9.4.2, 9.4.3, and from Lemma 4.2.4.2.4. I 

Theorem 9.4.5: h is a possibilities map, and IS is invariant in L5. 

Proof: By Lemma 9.3.3, 15 is invariant relative to h. By Lemma 9.4.4, h is a possibilities map 
relative to 15. We apply Lemma 4.2.4.2.6 to conclude that h is a possibilities map, and IS is an 
invariant I 

Since h^ is a possibilities map which fixes <T,L,V>, all invariants and pair-invariants from L4 
carry down to L5. We summarize the invariants for L5 as follows: 

Lemma 9.4.6: la, 13, 14, and 15 are invariant in L4, and Ja, J3 are pair-invariant in L4. 

Proof: Invariance of 15 is shown in Theorem 9.4.5. Since h M is a possibilities map which 
fixes <T,LV>, and la, 13, and 14 are invariant in L3, la, 13, and 14 are invariant in L4, by 
Lemma 4.2.4.3.5. Similarly since Ja, J3 are pair-invariant in L4, Ja and J3 are pair-invariant 
in L5, by I^mma 4.2.43.5. I 
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9.5 Level 6 Algebra and Mapping hgj 

At Level 6 we remove the global action tree, T. Since we have localized all preconditions in 
Level 5, the global tree can now be properly regarded as a "virtual" component of the state. 

L6 = (6 6 , 2 6 , a 6 , rj 

2 6 = {<L,V>}, where the components are: 

L - localUAS's(asinL3) 
V - value maps (as in L4) 

•6 = <L 0' V 

Lq, V fl - as in L4 

t 6 is identical to t 5 , except that all transitions involving T are discarded (T5.1a,b, T5.2a, T5 Ja, T5.4a,c,d). 

Let h^: L6 -♦ L5 be the augmentation map from Level 6 to Level 5 (Definition 4.2.5.1). Thus h^ is the 
identity map on events, and the state mapping maps <L,V> to all possible states <T,L,V> in 2j. 

Theorem 9.5.1: h 6S is a possibilities map. 

Proof: Follows immediately from Lemma 4.2.5.3. I 

By Lemma 42.5.2, h^ fixes <L,V>, so all invariants and pair-invariants for L and V from L5 carry down 
to L6. Most of these properties involve T, but all invariants from 14 except for 8.3.1e do not involve T, 
nor do the pair-invariants J3. We summarize these invariants and pair-invariants for L6 in the following 
Lemma. Let 14' denote 14 with 8.3.1e removed. (Thus 14* is just all invariants from 14 which apply to the 
local state <L,V>.) 

Lemma 9.5.2: 14' is invariant for L6, and J3 is pair-invariant in L6. 

Proof: Since h 65 is a possibilities map which fixes <L,V>, and 14' is invariant for <L,V> in L5, 
14' is invariant in L6, by Lemma 4.2.4.3.5. Similarly since J3 is pair-invariant for <L,V> in L5, 
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J3 is pair-invariant in \j6, by Lemma 4.2.4.3.5. 
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10. Distributed System Model 

Level 7 is our lowest-level model of the transaction system. At this level we partition the system 
state among nodes, and we use a communications model which takes into account arbitrary delays in 
message delivery. This model is a message-based distributed event-state algebra as described in Chapter 
4. Nodes communicate by sending and receiving messages via a message buffer. 

We require that each object and each action reside at a particular node (its "home node"). A 
node's state consists of a UAS and a value map for each object which resides there. We can thus view 
nodes as a grouping structure for the "tree locations" from Level 6. The mapping from node states (Level 
7) to local states at tree locations (Level 6) is a straightforward "explosion" of the node states. Similarly 
the Level 6 value map can be constructed from the value maps at each node. 

The only complexity in mapping from Level 7 to Level 6 is in modeling the communications 
delays at Level 7, since the communications events at Level 6 are "instantaneous." We resolve this 
discrepancy by treating messages themselves as locations. We regard a message as an initially empty 
"slot" for information; once this message is sent, the slot is filled. Since messages are never removed from 
the message buffer in our Level 7 model, it is natural to regard this message slot as a "location" at Level 6. 
The communications delay at Level 7 is explained at Level 6 by imagining that all messages are 
instantaneous, but that they are sent indirectly via another location (the message slot). 

10.1 Level 7 Algebra 

L7 = (8 ? , 2 ? , a v t ? ) 

The Level 7 Algebra is a message-based algebra as defined in Chapter 4 (Definition 4.3.2.1). Let 
Nodes = {l,2,...,n} name the nodes in the system, and let "bur name the message buffer. We will use T 
= 2Lj in this chapter, so mat we can subscript the state space without confusing these subspaces with the 
state spaces of higher levels in our algebra hierarchy. 

We assume that each object in the system resides at a particular node, and each action runs at a 
single node. We call this node the home node of the action or object Formally, 

home : tloc -* Nodes. (If A € accesses, then we will use home(A) synonymously with homc(object(A)). 
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Letobj(i) = {x € obj: home(x) = i}, 

act(i) = {A € act - {U} - accesses: home(A) = i}, 
tloc(i) = obj(i) U act(i). 

State Space: 

The local state at a node consists of a UAS for the node together with a "local" value map for each object 
whose home is at that node: 

Tj = {<l,v>: 1 € UAS, and v: obj(i) X act -+ values(obj) U {_!_}}, where i € Nodes. 

If D € T and i € Nodes, then we denote the UAS and value map components of D.i by D.i.l and D.i.v, 
respectively. We extend the definitions of V(x), V(x).holdcr, V(x). value, etc., from value maps to "local 
value maps" in the obvious way. 

The set of messages is defined as follows: 

Msgs = {#create(ij) A,d: ij € Nodes, A C act - {U}, d C act} 
U {#commit(i j) A,d: ij € Nodes, A € act - {U} * accesses, d C act} 

U { # aboiKi j) A: ij € Nodes, A € act - {U}} 

The message buffer space is I\ f = 9(Msgs). 

If D € T, and i € Nodes, then we abbreviate any function prop Dj] by tfproppli]. (This notation is 
similar to the notation introduced for locations, but note that i is now a node rather than a location.) 

Initial State: 

a 7 = D , where D fl is defined by 

D fl .buf=0, 

Vi € Nodes, D Q .i.l = T , the trivial UAS, and 

D .i.v(x,U) = init(x), Vx € obj(i), 
D iv(x,A) = JL, VA*U. 

The UAS and value map components of D Q .i correspond in a natural way to Lq and V Q . 
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Esfiffltsi 

6- consists of local events (create, commit, abort, perform), and communications events send M, 
receive M, for M € Msgs. Local events are similar to the corresponding local events at Level 6. 

At Level 7 we include a qualifier "(d)" on create, commit, and perform events. For example, a 
create event takes the form: create A (d), where d C act The preconditions for the create, commit and 
perform events requires that "d" be the set of known aborts at the node where the event occurs, "d" does 
not enter into any transitions. We can thus regard "(d)" as recording the set of known aborts when the 
event occurs; including this qualifier does not change the semantics of the events. The qualifier "(d)" is 
useful when we construct a mapping from Level 7 to Level 6: "local" events at Level 7 will map into a 
local event at Level 6 plus a sequence of communications events at Level 6. (Conceptually in this 
mapping we regard the occurrence of an event at a node as an occurrence at a single location at that node, 
followed by a broadcast of the event (with Level 6 communications events) to all other locations at that 
node. Of course, at Level 7 no "real" communications events occur.) Because these Level 6 
communications events require a "done" list, we extract it from the "(d)" in the Level 7 event 

(This device of qualifying events with a part of the state allows us to construct an 
event-homomorphic mapping between algebras. If the qualifier were not used, then the proper mapping 
from a lower-level event to the higher-level sequence of events would depend on the lower-level state as 
well as on the lower-level event i.e. the event mapping would not be event-homomorphic.) 

Transition Relation 

Although Definition 4.3.1.1 describes the total transition relation of a message-based algebra in 
terms of local transition relations for each component we will not describe local transition relations 
individually. Instead we present the total transition relation. It should be clear that preconditions and 
effects arc properly localized (i.e. the local transition relations could be constructed easily from our total 
transition relation). 

Lete€6 7 ,D€I\De = Dl. 

1. create A id) (A € act - {U}, home(creator(A)) = i, d Q act) 

PRECONDITIONS: 
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a. A C #vertices D [i] 

b. parent(A) € #active D [i] 

c. (B,A) €seq,B*A=»B€ tfdoneji] 

d. d = #aborted D [i] 
TRANSITIONS: 

a. #vertices D1 [i] «- #vertices D Ii] U {A} 

b. # slatus m [iK A) ♦- 'active' 

2. commit A(d) (A € act - {U} - accesses, home(A) = i, d C act) 
PRECONDITIONS: 

a. A € tfactiveji] 

b. tfchildrcn^iKA) Q ^done^i] 

c. d = #aborted D [i] 
TRANSITIONS: 

a. #status D1 pKA) ♦- 'committed' 

b. Vx € obj(i), D.i.v(x,A) * J_ =» 

Dl.i.v(x,A) «- ± 
Dl.i.v(x,parcnt(A)) ♦- Dj.v(x,A) 

3. abort A (A € act - {U}, home(A) = i) 
PRECONDITIONS: 

a. A € #active D [i] 
TRANSITIONS: 

a. #status D1 [iKA) «- 'aborted' 

b. Vx € obj(i), B € dcsc(A) ==» 

Dl.i.v(x,B) ♦- X 
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4. perform A.u (d) (A € accesses(x), u € values(x), home(x) = i, d C act) 
PRECONDITIONS: 

a. A € #active D (i] 

b. A € prop-desc(D.i.v(x).holder) 

c. u = D.i.v(x). value 

d. anc(A) C\ #aborted D [i] = 

e. d = #aborted D [i] 
TRANSITIONS: 

a. #status D1 [iKA) <— 'committed' 

b. Dl.i.v(x,parent(A)) «- update(AXu) 

5. send#create(i.nA.d (A € act - {U}, ij € Nodes, d Q act) 
PRECONDITIONS: 

a. A € #active D [i] 

b. d = #aborted D IiJ 
TRANSITIONS: 

a. Dl.buf ♦- D.buf U {#create(ij) A,d} 

6. receive #createfl.n A.d (A € act - {U}, ij € Nodes, d CJ act) 
PRECONDITIONS: 

a. #create(ij) A,d € D.buf 
TRANSITIONS: 

a. #vertices D1 lj] «— #verticeSjJj] U {A} 

b. A t Jjfverticesulj] =» #status D] [jKA) ♦- 'active' 
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c. #aborted D1 |j] ♦- # aborted^] U d 

d. Vx € objO), C € d, B € desc(C) => 

Dl.j.v(x,B) «- _L 



7. send #commitfi.i) A.d (A€act-{U}, ij€Nodes, dCact) 
PRECONDITIONS: 

a. A € # committed^] 

b. d = #aborted D [i] 
TRANSITIONS: 

a. Dl.buf*-D.bufU #commit(ij) A,d 

8. receive #commitfi.i) A.d (A € act - {U}, ij € Nodes, d C act) 
PRECONDITIONS: 

a. #commit(ij) A,d € D.buf 
TRANSITIONS: 

a. #vertices D1 OJ ♦- # vertices^] U {A} 

b. tfstatuSjjjUKA) *- 'committed' 

c. Vx € obj(j), Dj.v(xw\) * _L =» 

Dl.j.v(x,A) <- X 
Dl.j.v(x,parent(A)) «- D.j.v(x,A) 

d. #aborted D1 |j] ♦- # aborted^] U d 

e. Vx € obj: home(x) = j, C € d, B € desc(C) «=* 

DLj.v(x,B) «- J_ 

9. send^abortfLH A (A € act - {U}, y € Nodes) 
PRECONDITION: 

a. A € #aborted D [i] 
TRANSITIONS: 
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a. Dl.buf«-D.bufU #abort(iJ) 

10. receive #abort(i.i) A (A € act - {U}, ij € Nodes) 

PRECONDITION: 

a. #abort(ij)A €D.buf 
TRANSITIONS: 

a. #vertices D1 0] «— tfveiticeSjJj] U {A} 

b. #status D1 [jKA) <- 'aborted' 

c. Vx € obj(j), B € desc(A) =» 

Dl.j.v(x,B) <- _L 



10.2 Specification of Mapping h 76 

We define a (single-state) mapping from L7 to L6, h ?6 : L7 -* L6. (We abbreviate "hj 6 " as "h" 
in this chapter.) 

At this point we instantiate the (previously unspecified) set of locations, loc; we define 
loc = doc U 



We regard a message as a location because it is a container for information. The local information at this 
location is essentially the information contained in the message. As we explained above, we imagine that 
each message is a predefined "slot" for the particular combination of information mat it represents. 
Originally this slot is empty; when the message is sent, the slot is filled. 

State Mapping 

h: Zj — 2 6 is defined as follows. Let D € I\ h(D) = <L,V>, then 

V = valuemap(D), where valuemap(D) is defined as {((o,a),u): DJiome(o).v(o,a) = u}. 

Valuemap is defined exactly as we expect: the "total" valuemap for Level 6 is constructed by combining 
all local value maps. This mapping is so trivial that we can almost regard it as a simple change in 
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notation. 

L is defined by: 

1. If a € doc, then L(a) = D.home(a).l 

2. If a € Msgs, and a i D.buf, then L(a) = T H . 

3. If a € Msgs, and a € D.buf, then 

a. If o = #create(i j) A,d, then L(o) = T, where 
vertices T = {U,A} U d 

committedj. = 
abortedj. = d 

b. If a = #commit(i j) A,d, then L(a) = T, where 
vertices T = {U,A} U d 

committedj. = {A} 
abortedj = d 

c. If a = #abort(ij) A, then L(o) = T, where 
vertice&j. = {U,A} 

committedj. = 
aborted]- = {A} 



If o € doc, then L(a) is just the UAS at as home node. For locations which are messages, if the message 
has not been sent then its location has "no information" (i.e. its UAS is the trivial UAS, T u ). If the 
message has been sent, then the information in the UAS for its location corresponds exacdy to the 
information in the message, i.e. it describes what actions are known to be committed, aborted, or active as 
a result of the message. 

Event Mapping 

h: 8 ? -* 8 6 is defined as follows. Let onto be an arbitrary total order on 6 6 . For each node, i, let loc(i) 
be a distinguished doc whose home is that node. (We will use this doc to define an explicit "sender" for 
messages from that node. If such a doc does not exist, then it could be created just for this purpose.) 

h: create A (d) -♦ create A • «{@creatd{fi,a] A,d: fi = creator(A), home(a) = home(/J)}; ordS» 
commit A (d) -♦ commit A • «{@commidj3,a] A,d: fi = A, home(a) = homed)} > ordS» 
abort A — abort A • «{@abort|^,ol A: fi = A, home(a) = home(/*)} ; ord6» 
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perform A,u (d) -* perform A,u • «{@comm\l\fi,a] A,d: fi = x, homc(a) = homc(j8)}; ordS» 

h(send M) is defined as follows: 

IfM = #create(ij) A,d, then h: send M -+ @create[loc(i),M] A,d 
If M = #commit(ij) A,d, then h: send M -+ @commit[loc(i),M] A,d 
IfM = #abort(ij) A, then h: send M -* @abortlloc(i),M] A 

h(receive M) is defined as follows: 

IfM = #create(ij) A,d, then h: receive M -* «{@create[M,a] A,d: home(a) = j}; ord6» 
IfM = #commit(ij) A,d, then h: receive M -* «{@commit[M,a] A,d: home(a) = j}; ord6» 
IfM = #abort(ij) A, then h: receive M -► «{@abort(M,a] A: home(a) = j}; ord6» 

We map local events to the corresponding local event at Level 6, followed by a sequence of 
communications events that "inform" all other locations based at the same node of the event (Note that 
we use the qualifier "(d)" on local events at Level 7.) We map a send event to a communications event at 
Level 6 with the message slot as the desdnation. (The "sender" at Level 6 is an arbitrarily selected tloc at 
the sending node.) We map a receive event to a sequence of communications events at Level 6 with the 
message slot as the sender, and all docs at the receiving node as receivers. In general we map a single 
per-node event which affects the node's state to to a sequence of per- location events -- one for each doc 
whose home is that node. 

103 Proof of Possibilities Map for h 76 

We now show that h is a possibilities map. 

Lemma 103.1: h preserves initial states. 

Proof: Let h(D fl ) = <L,V>; then 

V = valuemapfDg) = Vq, and 
Ua) = T u if a € Msgs, since D Q .buf = 
If a € doc, then L(o) = D Q Jiome(o).l = T B . 
Thus L = L,,. I 
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Lemma 10.3.2: h preserves transitions. 

Proof: We must show that if D € PRE/e) n % v and h(D) € PRE 6 (h(e)) D 9> 6 , then h(De) 
= h(D)h(e). 

Let De = Dl, h(D) = <L,V>, h(Dl) = <L1,V1>, and <L,V>h(e) = <L',V>, then we must 
show that LI = L\ and VI = V. 

We argue the cases e = create A (d), e = send M, and e = receive M for M = #create(ij) 
A,d. Other cases are similar. 



1. e = create A (d). Let/3 = creator(A), i = home(0). 
h(e) = create A • «{@create[/J,a] A,d: home(a) = i}; ord6». 

From transitions T7.1a,b, we have 
DLbuf = D.buf, Dl.j = D.j V j * i, 
Dl.i.v = D.i.v, 

#vertices D1 [i] = tfverticeSj^i] U {A}, 
#status D1 [iKA) = 'active*. 

Thus VI = V, and Ll(o) = L(o) Va t tloc(i). If a € tloc(i), then 
©verticesLja] = ©verticesja] U {A}, and ©status^aKA) = 'active'. 

By inspection all events in h(e) only affect locations in tloc(i); thus L'(o) = L(o) 
= Ll(a) Va € tioc(i). 

Define relation •-» on tloc(i) as follows: ol *-* al «=» al = fi, or @createfj9,al] 

A,d precedes @creatc|/3,a2] A,d in ord6. (h-+ is reflexive.) Let <L2\V2*> = 

<L,V>u, where u is the prefix of h(e) up to and including event @create|^,o2] 

A,d. We can show inductively that 

@aborted L2 ^a2], 

V2'(o,A) = V(a,A) Va € obj(i), A € act, 

al •-♦ a2 =» A € @active u .[alj, 

~ (al •-» a2) =» AC ©verticesLylalJ. 

(We will not carry through the details of the induction here. The only subtle 
point is that event @CTeatc|j8,a2] A,d cannot affect V(a2) (if a2 € obj(i)): If B 
€ V(a2), then by Lemma 8.3.1a, B is live in L(a); thus B cannot be a descendant 
of an action in d. Note mat we can apply 8.3.1a because we know <L,V> € * 6 , 
and 14' is invariant in L6 by Lemma 9.S.2.) 

By applying the inductive result to the total sequence h(e), we conclude mat 

V = V and L'(a) = L(a) for all a in tloc(i). Thus VI = V, and LI = L\ 



-163- 



2. e = send M, M = #create(ij) A,d. 
h(e) = <gxreatc[loc(i),M] A,d. 

Dl.buf = D.buf U {M}; Dl.i = D.i Vi € Nodes. 

Since valuemap(D) does not depend on D.buf, V = V. But M C obj, so h(e) 
cannot affect V (in L6), =» VI = V. Thus VI = V. 

Obviously Ll(or) = L(ot) unless a = M. But Dl.i = D.i for all i € nodes, and if 
M' * M, then M' € D.buf *=» M' € Dl.buf. Thus L'(a) = L(o) for all a * M. 

For o = M, V(a) = T, where 
verticesp = {U,A} U d 
committedp = 
abortedp = d 

Let Ll(o) = Tl, Ua) = T, then 
vertices^ = verticeSj. U {A} U d 
committed^ = committed^ 
aborted^ = abortecL. U d 

But if M € D.buf, then T = T =» Tl = T. If M « D.buf, then T = T u -» Tl 
= T. 

Thus LI = L\ 

3. e = receive M, M = #create(i j) A,d. 

h(e) = «{@creatc[M,o]A,d:home(o) = j};on*J». 

At node j, A is added to # vertices^] (and made active if not already there), and 
d is merged into # aborted^]; descendants of d are discarded from D.j.v. 

We show LI = L' (the argument that VI = V is similar). 

Let a € loc. If a € Msgs, then clearly L'(o) = Ll(a) = L(a). If home(o) * j, 

then again L'(a) = Ll(a) = Ua). Otherwise let L(a) = T, Ll(a) = Tl, L'(o) 

= T. Then L(o) = D.j.l; L'(a) = Dl.j.1. 

Thus verticeSp = vertices^. U {A}, aborted^ = aborted^. U d (from transitions 

T7.a,c). 

But Tl differs from T by the effects of the message @creatc[/?,a] A.d, in h(e), 
which has identical effect (from transitions T6.a,c),=* Tl = T. Thus LI = L\ 



Lemma 10.3.3: h preserves preconditions. 

Proof: We must show that if D € PRE^e) D & 7 , and h(D) € \, then h(D) € PREgflKe)). 
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Leth(D) = <L,V>. . 

We argue the cases e = perform A,u (d), e = send M, and e = receive M for M 
#create(i j) A,d- Other cases are similar. 



1. e = perform A,u (d). Let x = object(A), i = home(x). 
h(e) = perform A,u • «{@commit[x,a] A,d: home(a) = x}; ord6». 

First we show that <L,V> € PRE 6 (perform A,u). L(x) = D.i.l, V(x,a) = 
D.i.v(x,a), by definition of h. 

a. A € #active D [i], by P7.4a, 
=» A € ©activejx]. 

b. A £ prop-desc(D.i.v(x).holder), by P7.4b, 
=» A € prop-desc(V(x).holder). 

c. u = D.i.v(x). value, by P7.4c, 
=» u = V(x).value. 

d. anc(A) n #aborted D [i] = 0, by P7.4d, 
=» anc(A) n @aborted L [x] = 0. 



Now let e' be the prefix of h(e) preceding @commit[x,a] A,d (for some a whose 
home is i), and let <L1,V1> = ^V*' (in L6). We show that <L1,V1> € 
PRE 6 (@commitlx,o] A,d): 

a. We must show that A € ©eommittedyjx]. But event perform A,u 
must be in e', => AC ©committed^x]. 

b. We must show d = @aborted L1 [x]. But d = #aborted D [i] by 
P7.4e, =► d = ©abortedjxj. 

But none of the events in e' can change @aborted L [x] (perform A,u 
obviously does not change @aborted L [x], and if event @commit[x,x] 
A,d occurs in e\ then d C ©abortedjx] already). Thus d = 
@aborted L1 [xJ. 



2. e = receive M, M = #create(i j) A,d. 
h(e) = «{@crcatelM,o] A,d: home(o) = j}; ord6». 

None of the events in h(e) affect L(M), and the precondition for each event 
@crcatc[M,a] A,d depends only on L(M). Thus it suffices to show that <L,V> € 
PRE 6 (@createlM,o] A,d) for all a. 
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But M € D.buf by P7.6a, so L(M) = T, where 
vertice&j. = {U,A} U d, 
committedj. = 0, 
abortedj. = d. 

Thus 

a. A € ©activeJM] 

b. d € ©abortedJM] 



3. e = send M, M = #create(i j) A,d 
h(e) = @crcate[loc(i),M] A,d. 

homc(loc(i)) = i, by definition, so L(loc(i)) = D.i.1. 



a. A € ^active^i], by P7.5a, 
=» A € @aetive L Poc(i)]. 

b. d = # aborted^], byP7.5b, 
=> d = @aborted L [loc(i)]. I 



Theorem 103.4: h is a possibilities map. 

Proof: By Lemma 10.3.1, h preserves initial states. By Lemmas 10.3.2 and 10.3.3, and Lemma 
4.2.2.6, h preserves events. Thus h is a possibilities map. I 

10.4 Mapping front Level 7 to Level 

We can now prove the main theorem of this thesis: valid execution sequences of our 
lowest-level model (Level 7), when suitably interpreted, generate only view-serializable action trees. 

Main Theorem: Let g: 8 ? -* 6 be defined by 

g = h *h °h °h °h *h °h 
n 76 n 65 n 54 n 43 n 32 n 21 n 10 

Let v € X 1 be some valid execution sequence in L7. Then Tjg(v) is a view-serializable action 
tree. 



166 



Proof: We have shown that each h j + 1 ] is a possibilities map (Theorems 6.4.4.1, 6.5.2.1, 7.4.5, 
8.4.5, 9.4.5, 9.5.1, and 10.3.4). By Lemma 4.2.2.5, each L + li is a valid interpretation. By 
repeated application of Lemma 4.1.3.2, g is a valid interpretation from L7 to L0. Thus v € 1^ 
=* g( v ) £ \ By Lemma 6.1.1, Tg(v) is view-scrializable. I 
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11. Conclusions 

11.1 Summary and Evaluation 

We have presented a detailed proof that a particular transaction system model satisfies our 
definition of internal consistency. The proof was structured on several levels, corresponding to different 
levels of abstraction of the transaction system. While the lowest-level model is still quite "abstract" in 
that it is far removed from an actual implementation, we feel that it captures many of the basic design 
decisions made for the Argus transaction system. 

We believe our work has made two contributions: First, we have formalized internal 
consistency and we have related this formal condition to a particular orphan detection strategy. Second, 
we have explored a method for multi-level correctness proofs which might be useful in other contexts. 

11.1.1 Orphan Detection and Internal Consistency 

Our definition of view-serializability appears to be a useful condition for internal consistency. 
In the development of the Argus orphan algorithm, designers have often relied on particular scenarios 
where inconsistencies arose to justify the need for including certain information in messages (or writing 
certain information to stable storage.) While this type of reasoning can demonstrate shortcomings in the 
algorithm, it cannot prove the algorithm correct (we cannot "prove by example.") Perhaps the results of 
this thesis, and future extensions of these results, can partly subsume this "reasoning by scenario." 

Although we have ignored crashes in our system models, the view-serializability condition 
appears to be applicable in an environment with crashes. We have applied this condition to scenarios of 
inconsistencies in Argus which result from crashes; these inconsistencies can be explained by showing 
that an action does not have a scrializable view tree. (Since view-serializability is a sufficient condition for 
internal consistency, any inconsistency should be explicable by the absence of a serializable view tree.) 

ll.U Algebraic Models 

The multi-level structure of our correctness proof yields at least two benefits: First, since 
adjacent levels are generally closely related, the possibilities maps (and proofs of possibilities maps) 
between adjacent levels are relatively simple. Although we employ many levels, overall complexity is 
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reduced and understandability of the mappings is enhanced. 

Second, because the higher-level models are more abstract, they might prove to be useful 
abstractions of different implementations. At Level 1 we describe the ANC-ABORT property, at Level 2 
we describe a specific orphan detection precondition, and only at Level 5 do we explain how this 
detection is carried out locally by piggybacking aborts lists onto messages. A different orphan strategy 
could be described at lower levels, but the higher-level models might still apply. As a trivial example, if 
all orphans are always exterminated immediately, then it is easy to show that condition ANC-ABORT 
from Level 1 is satisfied. Thus the correctness proof from Level 1 could be carried over to a system using 
immediate extermination. As another example, if we change the specific information piggybacked onto 
create and commit messages at Level S (for example, we might choose to send only a covering subset of 
the known aborts set) then the Level 4 model might still apply. 

Our notion of "homomorphism" is unusual in mat we allow "possibilities" mappings to sets of 
states at higher levels. This approach allows us to explain the "auxiliary state" technique as a particular 
kind of possibilities map. For our algebra hierarchy, we used a multiple-state augmention mapping 
between Levels 6 and 5. We speculate that the use of possibilities maps instead of auxiliary state variables 
might simplify some correctness proofs. 

11.2 Directions for Further Research 

The application of formal techniques to distributed transaction systems is a vast topic; we limit 
our discussion to three possible extensions of our work. 

11.11 Crashes 

The most glaring deficiency of our model is that we do not consider node crashes. Node crashes 
are a more difficult problem than explicit aborts because the orphans created by a node crash might be 
ancestors (or relatives) of actions which ran at the crashed node and committed. The "infected" ancestor 
can commit arbitrarily far up the action tree before the crash is discovered (though it will eventually be 
caught at the top level during two-phase commit if it is not caught sooner). 

The (visible-data-closed) view tree which we used to prove view-serialuability for the explicit 
aborts case will not work for a crash modeL It is possible mat a datastep can be "visible" to another access 
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since it has committed to their least common ancestor, but the effect of this datastcp might have been 
undone by a crash. Consider the tree of Fig. 11.1, for example. Object x has initial value 0. Action A 
spawns concurrent children Al and A2. Action Al runs, increments x, and commits to A. Then x's node 
crashes, allowing A2 to get a lock on x. Action A2 cannot see the effects of Al, because x's node crashes 
after Al commits to A. A2's view is consistent, because there exists a serializable view tree for A2, but 
this view tree does not include Al. (A2 is an orphan, because A is an orphan, but A2 is not yet a "bad" 
orphan.) Note also that if A2 commits to A, then A's view becomes inconsistent Thus an orphan 
detection strategy for a crash model must place restrictions on the commit of actions; for the explicit 
aborts case, we have shown that it is sufficient to put a precondition on perform events. 

We speculate that a high-level notion of "depending on a crash" could be developed to parallel 
our notion of depending on an abort, and that a sufficient condition for view-serializability could be 
expressed in terms of these dependencies. Piggybacking of crash count information would appear at 
lower levels. A better approach would be to somehow unify aborts and crashes (i.e., treat them both as 
particular cases of a higher-level event), but we have made little progress in this direction. 



Fig. 11.1. Consistent View of Orphan Arising from a Node Crash 




orphans 



(x's node crashes 
after Al commits) 
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11.2.2 Lower Level Models . 

Although our lowest-level model is "distributed," it ignores many of the optimizations and 
complications of a real orphan detection algorithm. A more satisfying "correctness proof would extend 
our bottom level to even lower-level models which are closer to a real design. At least two areas for 
refinement may be explored: First, since the system history of aborts will grow without bound, any 
operational orphan algorithm will not send DONE in entirety on each message. Reducing this overhead 
will require some connection information or garbage collection scheme (perhaps using some variant of 
orphan expiration [Nelson81]). It would be useful to prove mat these modifications are indeed 
optimizations in that they do not violate internal consistency. 

Second, our model describes the possible flows of information, but it does not describe strategies 
for actually sending messages. (For example, do actions inform descendants immediately when they 
commit, or do they answer to queries from descendants?) Since our work focuses on correctness of 
reachable states, we have been able to ignore these questions. Of equal interest to designers, though, are 
properties of liveness (for example, will a commit message ever arrive) and bounds on delays. 
Formalization of these properties might require fundamentally different mechanisms. 

As tower-level models become more detailed, they will approach specifications for the programs 
of a transaction system. At this point the boundary blurs between these correctness proofs and program 
verification. 

11.2.3 User-Defined Atomic Data Types 

We have limited the objects in our model to simple atomic objects implemented using mutual 
exclusion locks and a stack of versions. For some applications these objects might be inefficient: different 
implementations of atomic objects might provide additional concurrency or a more efficient backup and 
recovery mechanism. As explained in [Weihl82J, &e "atomicity" of a data type depends on the semantics 
of the operations available to users of that type. As a trivial example, if a type is "immutable" (none of 
the operations change the abstract object), then it is automatically atomic. Our serializability condition is 
insufficient to describe this more general notion of atomicity. 

More general "user-defined" atomic types can be constructed from basic atomic objects (like 
those in our model) and completely nonatomic objects (which provide no synchronization or recovery). 



171 



(Again, see [Weihl82] for examples of these constructions.) Because the effects of aborted actions might 
not be undone, undetected orphans can violate external consistency through non-atomic data (with 
catastrophic effects). Thus an orphan detection strategy is more important for systems which allow 
non-atomic objects. Although orphan detection does not guarantee view-serializability for systems with 
non-atomic objects, it might guarantee weaker properties which are useful to programmers trying to use 
- non-atomic objects to construct atomic types. We have begun to explore these properties (and more 
complex models which incorporate general atomic types). For example, it is relatively easy to show that 
the orphan detection strategy we have modeled constrains the order of datasteps on a non-atomic object 
to be consistent with the sequence ordering. (Without orphan detection, even this weak condition might 
not hold.) 
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Appendix I - Notational Conventions 



Fig. I.l. Conventions for Figures 



The action tree, 


T, is usually implicit 






/ 

A,c 


A € committedj 


/ 

A, a 


A € aborted T 



/ 



A = parent(B) 



/ 



A € prop-anc(B) 



A € anc(B) 




prop-anc(B) D prop-desc(A) C committedj 



A f B --- (A,B) € seq T 



A ^ B --- (A,B) € data T 
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Fig. 1.2. Cross-Reference of Invariants to Lemmas 



Invariant 


Symbol 


la 




Ja 




Sa 




13 




J3 




14 




14' 




15 





Lemma(s) 

6.3.1.1.2, 6.3.1.1.4, 6.3.2.2, 6.3.3.1, and 6.3.3.2 

6.3.1.1.1, 6.3.1.1.3, 6.3.3.3, and 6.3.3.4 

6.3.1.2.1 through 6.3.1.2.14 

7.3.2 

7.3.1 

8.3.1 

8.3.1 except for 8.3. le 

9.3.3 
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